nginx ریورس پراکسی: مکمل سیٹ اپ ٹیوٹوریل

nginx ریورس پراکسی ایسا nginx سرور ہے جو ایک یا زیادہ بیک اینڈ ایپلیکیشنز کی طرف سے آنے والی ان باؤنڈ درخواستیں وصول کرتا ہے، پھر ہر درخواست کو درست بیک اینڈ تک پہنچاتا ہے اور جواب کلائنٹ کو واپس بھیجتا ہے۔ یہ ٹیوٹوریل آپ کو کاپی کے لیے تیار مکمل nginx ریورس پراکسی کنفیگریشن دیتا ہے: proxy_pass اور فارورڈ کیے گئے ہیڈرز کے ساتھ ایک مکمل سرور بلاک، اپ سٹریم لوڈ بیلنسنگ، SSL termination، ویب ساکٹ سپورٹ، بفرنگ اور ٹائم آؤٹ ٹیوننگ، gzip، location پر مبنی روٹنگ، اور 502 و 504 خرابیوں کا حل جن پر عموما لوگ اٹک جاتے ہیں۔

آخر تک آپ کے پاس ایک چلنے کے قابل nginx ریورس پراکسی سیٹ اپ، یہ واضح سمجھ ہوگی کہ اس کے حصے آپس میں کیسے جڑتے ہیں، اور یہ حقیقت پسندانہ اندازہ بھی ہوگا کہ nginx ریورس پراکسی کہاں مناسب ٹول نہیں رہتی اور فارورڈ یا رہائشی پراکسی اس کی جگہ لیتی ہے۔

DataImpulse ایک اخلاقی پراکسی فراہم کنندہ ہے جو 195 ممالک میں 90 ملین سے زیادہ رہائشی، موبائل، اور ڈیٹا سینٹر IP ایڈریسز فراہم کرتا ہے۔ یہ 1 ڈالر فی GB سے شروع ہونے والا pay-as-you-go ماڈل استعمال کرتا ہے، جس میں ٹریفک کی میعاد ختم نہیں ہوتی، اور اسے ویب سکریپنگ، اشتہار کی تصدیق، قیمتوں کی نگرانی، مارکیٹ ریسرچ، اور ملٹی اکاؤنٹ مینجمنٹ کے لیے استعمال کیا جاتا ہے۔

کیا nginx ایک ریورس پراکسی ہے، اور یہ کیسے کام کرتا ہے؟

جی ہاں، nginx سب سے زیادہ استعمال ہونے والی ریورس پراکسیز میں شامل ہے، اور ریورس پراکسینگ اس کی بنیادی صلاحیت ہے، کوئی اضافی فیچر نہیں۔ ریورس پراکسی آپ کے بیک اینڈ سرورز کے سامنے ہوتی ہے، ایک عوامی ہوسٹ نیم پر کلائنٹ کنکشنز قبول کرتی ہے، اور ہر درخواست کو ایسی اندرونی ایپلیکیشن تک روٹ کرتی ہے جسے کلائنٹ براہ راست کبھی نہیں دیکھتا۔

چلتے ہوئے اجزا کو واضح رکھنے کے لیے یہ گائیڈ ایک سادہ نامی ماڈل استعمال کرتی ہے۔ اسے 5 تہوں والا nginx ریورس پراکسی ماڈل کہہ لیں۔ نیچے دی گئی ہر قابل عمل کنفیگریشن انہی تہوں کو ترتیب سے جوڑنے کا نتیجہ ہے:

• لسنر۔ listen ڈائریکٹو اور server_name طے کرتے ہیں کہ کون سی درخواستیں اس بلاک سے متعلق ہیں (پورٹ 80، پورٹ 443، کون سا ہوسٹ نیم)۔
• Location روٹنگ۔ location بلاکس آنے والے راستوں کو تقسیم کرتے ہیں تاکہ /api/، /static/، اور / ہر ایک اپنی جگہ جا سکے۔
• اپ سٹریم۔ upstream بلاک بیک اینڈ سرورز کے پول اور لوڈ بیلنسنگ کے طریقے کو نام دیتا ہے۔
• ہیڈرز۔ proxy_set_header لائنیں اصل Host اور کلائنٹ IP محفوظ رکھتی ہیں تاکہ بیک اینڈ اصل درخواست دیکھے، nginx کو نہیں۔
• TLS۔ listen 443 پر ssl_certificate nginx ہی پر HTTPS ختم کرتا ہے تاکہ بیک اینڈز اندرونی طور پر سادہ HTTP استعمال کر سکیں۔

اگر آپ ابھی تک پراکسی کی دو سمتوں کے درمیان فیصلہ کر رہے ہیں تو ہماری وضاحت ریورس پراکسی بمقابلہ فارورڈ پراکسی اس تصور کو مکمل طور پر سمجھاتی ہے۔ یہ مضمون صرف ریورس صورت پر ہے۔ آؤٹ باؤنڈ، کلائنٹ سائیڈ سیٹ اپ کے لیے ساتھی گائیڈ nginx فارورڈ پراکسی دیکھیں۔

شروع کرنے سے پہلے آپ کو کیا چاہیے؟

آپ کو ایک Linux سرور چاہیے جس پر nginx نصب ہو، کم از کم ایک بیک اینڈ ایپلیکیشن جو مقامی پورٹ پر سن رہی ہو، اور HTTPS کے لیے TLS سرٹیفکیٹ درکار ہوگا۔ ریورس پراکسینگ صرف معیاری nginx بلڈ استعمال کرتی ہے، لہذا کسی کسٹم ماڈیول یا دوبارہ کمپائل کرنے کی ضرورت نہیں۔

کچھ بھی بدلنے سے پہلے تصدیق کر لیں کہ nginx موجود ہے اور آپ کی کنفیگریشن درست ہے:

nginx -v
sudo nginx -t

nginx -t پوری کنفیگریشن کو پارس کرتا ہے اور فائل اور لائن نمبر کے ساتھ syntax کی خرابیاں بتاتا ہے۔ اسے اس ٹیوٹوریل میں ہر تبدیلی کے بعد چلائیں، کیونکہ nginx خراب کنفیگ دوبارہ لوڈ نہیں کرے گا اور پرانی کنفیگ چلتی رہے گی۔ اپنی ڈسٹری بیوشن کے مطابق ریورس پراکسی server بلاکس /etc/nginx/conf.d/ یا /etc/nginx/sites-available/ میں رکھیں، اور ٹیسٹ پاس ہونے کے بعد sudo nginx -s reload سے دوبارہ لوڈ کریں۔ بیک اینڈ ایڈریس بھی تیار رکھیں، مثلا 127.0.0.1:3000 پر ایک Node یا Python ایپ، کیونکہ proxy_pass اسی طرف اشارہ کرے گا۔

nginx ریورس پراکسی مرحلہ وار کیسے سیٹ اپ کریں؟

ایک ہی server بلاک سے شروع کریں جو پورٹ 80 پر سنتا ہو، proxy_pass کے ذریعے ہر درخواست بیک اینڈ کو بھیجتا ہو، اور فارورڈ کیے گئے ہیڈرز سیٹ کرتا ہے۔ پھر لوڈ بیلنسنگ، TLS، ویب ساکٹس، بفرنگ، اور gzip شامل کریں۔ یہ پہلا بلاک nginx ریورس پراکسی کا کم سے کم قابل عمل سیٹ اپ ہے:

server {
    listen 80;
    server_name app.example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host              $host;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

یہ چار proxy_set_header لائنیں اختیاری نہیں ہیں۔ ان کے بغیر بیک اینڈ nginx کو کلائنٹ سمجھتا ہے، غلط IP لاگ کرتا ہے، اور خراب ری ڈائریکٹ URLs بنا سکتا ہے۔ Host درخواست کیا گیا hostname محفوظ رکھتا ہے، X-Real-IP اور X-Forwarded-For اصل کلائنٹ ایڈریس پہنچاتے ہیں، اور X-Forwarded-Proto ایپ کو بتاتا ہے کہ اصل درخواست HTTP تھی یا HTTPS۔

اپ سٹریم لوڈ بیلنسنگ شامل کریں۔ کئی بیک اینڈ انسٹینسز کے سامنے رکھنے کے لیے ایک upstream بلاک بنائیں اور proxy_pass کو اس کے نام کی طرف اشارہ کرائیں۔ least_conn طریقہ ہر درخواست کو اس انسٹینس تک بھیجتا ہے جس پر فعال کنکشنز سب سے کم ہوں:

upstream app_backend {
    least_conn;
    server 10.0.0.11:3000;
    server 10.0.0.12:3000;
    server 10.0.0.13:3000 backup;
}

server {
    listen 80;
    server_name app.example.com;

    location / {
        proxy_pass http://app_backend;
        proxy_set_header Host              $host;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

backup سرور صرف اس وقت ٹریفک لیتا ہے جب پرائمری سرورز ڈاؤن ہوں۔ اگر sticky sessions کے لیے ایک ہی کلائنٹ کو ایک ہی بیک اینڈ سے جوڑے رکھنا ہو تو least_conn کے بجائے ip_hash استعمال کریں۔

پورٹ 443 پر SSL ختم کریں۔ پروڈکشن ریورس پراکسیز کو HTTPS فراہم کرنا چاہیے اور سادہ HTTP کو ری ڈائریکٹ کرنا چاہیے۔ nginx TLS سنبھالتا ہے تاکہ آپ کے بیک اینڈز اندرونی طور پر سادہ HTTP پر رہ سکیں:

server {
    listen 443 ssl;
    server_name app.example.com;

    ssl_certificate     /etc/letsencrypt/live/app.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/app.example.com/privkey.pem;
    ssl_protocols       TLSv1.2 TLSv1.3;

    location / {
        proxy_pass http://app_backend;
        proxy_set_header Host              $host;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

server {
    listen 80;
    server_name app.example.com;
    return 301 https://$host$request_uri;
}

ویب ساکٹس کی سپورٹ۔ ویب ساکٹ کنکشنز HTTP کے طور پر شروع ہوتے ہیں اور پھر اپ گریڈ ہوتے ہیں، اس لیے nginx کو Upgrade اور Connection ہیڈرز آگے بھیجنے اور HTTP/1.1 استعمال کرنے کی ضرورت ہے۔ ریئل ٹائم راستوں کے لیے الگ location رکھیں:

location /ws/ {
    proxy_pass http://app_backend;
    proxy_http_version 1.1;
    proxy_set_header Upgrade    $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host       $host;
    proxy_read_timeout 3600s;
}

لمبا proxy_read_timeout idle ساکٹس کو سیشن کے دوران بند ہونے سے روکتا ہے، جو لائیو کنکشنز ٹوٹنے کی ایک عام وجہ ہے۔

بفرنگ اور ٹائم آؤٹس ٹیون کریں۔ ڈیفالٹس محتاط ہوتے ہیں؛ سست بیک اینڈز کے لیے واضح ویلیوز بہتر رہتی ہیں تاکہ nginx ایپ کے جواب دینے سے پہلے کنکشن بند نہ کرے:

location / {
    proxy_pass http://app_backend;
    proxy_connect_timeout 5s;
    proxy_send_timeout    60s;
    proxy_read_timeout    60s;
    proxy_buffering       on;
    proxy_buffers         16 16k;
    proxy_buffer_size     32k;
}

gzip فعال کریں۔ پراکسی کیے گئے جوابات کو کمپریس کرنے سے ٹیکسٹ ایسٹس کے لیے بینڈوتھ کم ہوتی ہے۔ اسے http بلاک میں رکھیں تاکہ یہ پوری سائٹ پر لاگو ہو:

gzip on;
gzip_types text/plain text/css application/json application/javascript;
gzip_min_length 1024;
gzip_comp_level 5;

راستے کے مطابق روٹ کریں۔ ریورس پراکسی مختلف location prefixes کو مختلف upstreams سے ملا کر کئی سروسز کے سامنے آ سکتی ہے، اور بیک اینڈ کو چھوئے بغیر براہ راست ڈسک سے static فائلیں فراہم کر سکتی ہے:

server {
    listen 80;
    server_name example.com;

    location /api/ {
        proxy_pass http://api_backend;
        proxy_set_header Host $host;
    }

    location /static/ {
        root /var/www/assets;
    }

    location / {
        proxy_pass http://web_backend;
        proxy_set_header Host $host;
    }
}

آپ کیسے تصدیق کریں کہ nginx ریورس پراکسی کام کر رہا ہے؟

nginx کو دوبارہ لوڈ کریں، پھر عوامی hostname پر درخواست بھیجیں اور تصدیق کریں کہ جواب آپ کے بیک اینڈ سے آ رہا ہے nginx کے ڈیفالٹ صفحے سے نہیں۔ پہلے کنفیگ ٹیسٹ کریں تاکہ کوئی ٹائپو سائٹ کو بند نہ کر دے:

sudo nginx -t && sudo nginx -s reload
curl -I http://app.example.com

ریسپانس ہیڈرز میں 200 یا متوقع ری ڈائریکٹ کا مطلب ہے کہ روٹنگ کام کر رہی ہے۔ یہ ثابت کرنے کے لیے کہ بیک اینڈ فارورڈ کیے گئے ہیڈرز وصول کر رہا ہے، اس کا access log یا کوئی echo اینڈ پوائنٹ دیکھیں اور تصدیق کریں کہ یہ X-Forwarded-For سے اصل کلائنٹ IP دیکھ رہا ہے، 127.0.0.1 نہیں۔ آپ DNS کو بائی پاس کر کے اور hostname کو spoof کرتے ہوئے براہ راست پراکسی کو بھی ٹارگٹ کر سکتے ہیں:

curl -H "Host: app.example.com" http://127.0.0.1

HTTPS کے لیے curl -I https://app.example.com چلائیں اور تصدیق کریں کہ سرٹیفکیٹ قبول ہو رہا ہے اور درخواست ڈاؤن گریڈ نہیں ہوئی۔ اگر بیک اینڈ غلط اسکیم کے ساتھ لنکس یا ری ڈائریکٹس بناتا ہے، تو وجہ تقریبا ہمیشہ غائب X-Forwarded-Proto ہیڈر ہوتا ہے، TLS کی خرابی نہیں۔

آپ 502 اور 504 خرابیوں کو کیسے حل کریں؟

502 Bad Gateway کا مطلب ہے کہ nginx upstream تک پہنچا مگر اسے غلط یا مسترد شدہ جواب ملا، جبکہ 504 Gateway Timeout کا مطلب ہے کہ upstream نے کنکشن قبول کیا مگر وقت پر جواب نہیں دیا۔ دونوں upstream کے مسائل ہیں، nginx کے bugs نہیں، اور error log اصل وجہ بتاتا ہے۔ درخواست دوبارہ چلا کر اسے live دیکھیں:

sudo tail -f /var/log/nginx/error.log
# [error] connect() failed (111: Connection refused) while connecting to upstream

عام وجوہات کو ترتیب سے دیکھیں:

• 502، کنکشن مسترد۔ بیک اینڈ چل نہیں رہا، یا proxy_pass کے ٹارگٹ سے مختلف ایڈریس یا پورٹ پر سن رہا ہے۔ خود سرور پر curl http://127.0.0.1:3000 سے تصدیق کریں۔
• 502، SELinux یا فائر وال۔ RHEL فیملی سسٹمز پر SELinux nginx کو آؤٹ باؤنڈ کنکشنز کھولنے سے روک سکتا ہے جب تک آپ setsebool -P httpd_can_network_connect 1 نہ چلائیں۔
• 504، سست بیک اینڈ۔ ایپ جواب دینے میں proxy_read_timeout سے زیادہ وقت لیتی ہے۔ اسے عالمی سطح پر چھپانے کے بجائے اسی location کے لیے timeout بڑھائیں، یا سست کوئری ٹھیک کریں۔
• 502، بڑے ہیڈرز۔ اگر بیک اینڈ بڑے ریسپانس ہیڈرز بھیجتا ہے تو وہ پراکسی بفرز کو اوورفلو کر سکتا ہے۔ proxy_buffer_size اور proxy_buffers بڑھائیں۔
• غلط upstream کا انتخاب۔ اگر upstream pool میں ایک سرور ڈاؤن ہو تو nginx اسے غیر صحت مند نشان زد کر کے اگلا سرور آزماتا ہے، اس لیے وقفے وقفے سے آنے والے 502s اکثر ایک ہی خراب بیک اینڈ کی طرف اشارہ کرتے ہیں۔

کون سا ریورس پراکسی مناسب ہے، اور آپ کو کب مختلف پراکسی کی ضرورت ہے؟

nginx ریورس پراکسی اس وقت استعمال کریں جب آپ TLS ختم کر رہے ہوں، لوڈ بیلنسنگ کر رہے ہوں، یا اپنے سرورز کے سامنے راستے روٹ کر رہے ہوں۔ فارورڈ یا رہائشی پراکسی اس وقت چاہیے جب اصل کام بہت سی IPs سے آؤٹ باؤنڈ درخواستیں بھیجنا ہو۔ nginx ان باؤنڈ کاموں میں بہترین ہے، آؤٹ باؤنڈ گردش کے لیے نہیں بنایا گیا۔ فیصلہ کرنے کے لیے یہ خلاصہ دیکھیں:

• nginx ریورس پراکسی اس وقت استعمال کریں جب آپ بیک اینڈ ہوسٹ کر رہے ہوں، کئی اندرونی سروسز کے لیے ایک عوامی HTTPS اینڈ پوائنٹ چاہتے ہوں، انسٹینسز کے درمیان لوڈ بیلنسنگ چاہیے ہو، یا edge پر کیشنگ اور gzip درکار ہو۔
• nginx کو اپنی پراکسی کے طور پر اس وقت نہ چنیں جب مقصد ایسی آؤٹ باؤنڈ درخواستیں ہوں جو کئی مختلف IPs یا ممالک سے آتی نظر آنی چاہییں، کیونکہ ریورس پراکسی آپ کے ایک ہی سرور IP سے نکلتی ہے اور ایڈریسز نہیں گھما سکتی۔

خاص طور پر ریورس پراکسیز میں، nginx، Caddy، اور HAProxy مختلف trade-offs کرتے ہیں:

بھاری آؤٹ باؤنڈ آٹومیشن کے لیے ہماری ویب سکریپنگ کے بہترین طریقوں والی گائیڈ گردش اور ریٹ کنٹرول کا احاطہ کرتی ہے، اور ڈیٹا سینٹر پراکسیز یا موبائل پراکسیز ان کاموں کے لیے موزوں ہیں جہاں لاگت یا کیریئر IPs رہائشی درستگی سے زیادہ اہم ہوں۔

nginx ریورس پراکسی کی حدود اور خطرات کیا ہیں؟

nginx ریورس پراکسی ان باؤنڈ ٹریفک کے لیے طاقتور ہے، لیکن اس کی واضح حدود ہیں: یہ آؤٹ باؤنڈ IPs نہیں گھما سکتی، غلط کنفیگر کیے گئے ہیڈرز کلائنٹ کو ظاہر یا چھپا سکتے ہیں، اور یہ ایک اضافی آپریشنل جزو بن جاتی ہے جسے پیچ اور مانیٹر کرنا پڑتا ہے۔ یہ بات ذہن میں رکھنے سے توقعات حقیقت پسندانہ رہتی ہیں۔

• واحد ایگزٹ IP۔ پراکسی سے ہر آؤٹ باؤنڈ درخواست سرور کے اپنے IP کے ذریعے نکلتی ہے، اس لیے ریورس پراکسی ایسے کاموں میں مدد نہیں دیتی جن کے لیے کئی سورس ایڈریسز درکار ہوں۔
• ہیڈر کی غلطیاں خاموش رہتی ہیں۔ X-Forwarded-For بھولنے سے آپ کی ایپ اور اس کی ریٹ لمیٹنگ کے لیے اصل کلائنٹ IP چھپ جاتی ہے؛ X-Forwarded-Proto بھولنے سے HTTPS ری ڈائریکٹس ٹوٹ جاتی ہیں۔ nginx آپ کو خبردار نہیں کرے گا۔
• TLS اور سرٹیفکیٹ کی دیکھ بھال۔ سرٹیفکیٹس کی میعاد ختم ہو جاتی ہے، اس لیے تجدید اور reloads کی ذمہ داری آپ پر ہے، عموما certbot اور ایک cron job یا systemd timer کے ذریعے۔
• ناکامی کا ایک نیا نکتہ۔ پراکسی اب کریٹیکل پاتھ میں ہے؛ اگر یہ ڈاؤن ہو جائے تو اس کے پیچھے موجود ہر بیک اینڈ ناقابل رسائی ہو جاتا ہے، اسی لیے health checks اور مانیٹرنگ اہم ہیں۔
• آؤٹ باؤنڈ گمنامی کا ٹول نہیں۔ ریورس پراکسی درخواستوں کے ماخذ کو چھپانے کے لیے نہیں بنائی گئی۔ یہ فارورڈ پراکسی کا کام ہے۔

nginx کوئی DataImpulse پروڈکٹ نہیں ہے، اور DataImpulse منیجڈ سکریپنگ API یا مفت ویب پراکسی فروخت نہیں کرتا۔ جہاں nginx موزوں ہو وہاں اسے خود چلائیں؛ جہاں آؤٹ باؤنڈ اسکیل درکار ہو، DataImpulse اپنے IPs اخلاقی پراکسیز کے طور پر ان صارفین سے حاصل کرتا ہے جو رضاکارانہ طور پر شامل ہوتے ہیں اور معاوضہ پاتے ہیں۔ آخری اپ ڈیٹ: 2026-07-22۔

اکثر پوچھے گئے سوالات

متعلقہ گائیڈز

• NGINX فارورڈ پراکسی
• Cloudflare ریورس پراکسی
• Docker ریورس پراکسی

آؤٹ باؤنڈ IPs چاہییں جنہیں nginx گھما نہیں سکتا؟

ریورس پراکسی ان باؤنڈ ٹریفک سنبھالتی ہے، لیکن جب آپ کے کام کو کئی حقیقی IPs سے آؤٹ باؤنڈ درخواستیں بھیجنے کی ضرورت ہو تو DataImpulse 195 ممالک میں 90M+ روٹیٹنگ رہائشی، موبائل، اور ڈیٹا سینٹر IPs فراہم کرتا ہے۔ قیمت 1 ڈالر فی GB سے شروع ہونے والے pay-as-you-go ماڈل پر ہے، جس میں ٹریفک کی میعاد ختم نہیں ہوتی۔ گیٹ وے کریڈینشلز حاصل کرنے اور اپنے کلائنٹ کو پول میں روٹ کرنے کے لیے اکاؤنٹ بنائیں۔