nginx فارورڈ پراکسی کیسے سیٹ اپ کریں (HTTP + HTTPS)

nginx فارورڈ پراکسی ایسا nginx سرور ہے جسے کلائنٹ کی باہر جانے والی درخواستیں بیرونی منزلوں تک پہنچانے کے لیے ترتیب دیا جاتا ہے۔ یہ اوریجن سرور کے بجائے کلائنٹ کی طرف سے کام کرتا ہے۔ یہ ٹیوٹوریل HTTP اور HTTPS دونوں کے لیے کام کرنے والی nginx فارورڈ پراکسی بنانے، curl سے اسے جانچنے، رسائی کنٹرول شامل کرنے، اور جب ایک سرور IP کافی نہ ہو تو اسے ریزیڈنشل پول کے ساتھ جوڑنے کے مراحل بتاتا ہے۔

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

DataImpulse اخلاقی پراکسیز فراہم کرنے والی سروس ہے جو 195 ممالک میں 9 کروڑ سے زائد ریزیڈنشل، موبائل، اور ڈیٹا سینٹر IP ایڈریسز دیتی ہے۔ اس کا ادائیگی بمطابق استعمال ماڈل 1 ڈالر فی GB سے شروع ہوتا ہے، ٹریفک ختم نہیں ہوتی، اور اسے ویب اسکریپنگ، اشتہارات کی توثیق، قیمتوں کی نگرانی، مارکیٹ ریسرچ، اور متعدد اکاؤنٹس کے انتظام کے لیے استعمال کیا جاتا ہے۔

nginx فارورڈ پراکسی بمقابلہ ریورس پراکسی کیا ہے؟

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

اس نکتے کو ذہن میں رکھیں، کیونکہ زیادہ تر nginx ٹیوٹوریلز ریورس صورت بیان کرتے ہیں:

• فارورڈ پراکسی: کلائنٹ کو اس پراکسی کے ذریعے ٹریفک بھیجنے کے لیے ترتیب دیا جاتا ہے، جس سے کلائنٹ ہدف سے چھپ جاتا ہے۔ یہ وہی ہے جو آپ curl -x یا براؤزر کی پراکسی سیٹنگ سے سیٹ کرتے ہیں۔
• ریورس پراکسی: کلائنٹ ایک عوامی ہوسٹ نام سے معمول کے مطابق جڑتا ہے؛ nginx درخواست کو اس کے پیچھے موجود بیک اینڈ پول تک پہنچاتا ہے، اور کلائنٹ کو کبھی معلوم نہیں ہوتا کہ کوئی پراکسی موجود ہے۔

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

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

آپ کو ایک عوامی IP والا Linux سرور، انسٹال شدہ nginx، اور HTTPS کے لیے nginx کی ایسی بلڈ درکار ہے جس میں CONNECT ماڈیول شامل ہو۔ سادہ HTTP فارورڈنگ کسی بھی عام nginx پر کام کرتی ہے۔

چیک کریں کہ آیا آپ کی بائنری میں پہلے سے CONNECT سپورٹ موجود ہے:

nginx -V 2>&1 | grep -o proxy_connect
# empty output means the module is not compiled in

عام nginx میں HTTP CONNECT طریقے کے لیے کوئی ڈائریکٹو نہیں ہوتا، جبکہ HTTPS ٹنلنگ کے لیے یہی طریقہ درکار ہے، اس لیے براؤزرز اور curl غیر ترمیم شدہ بلڈ کے ذریعے TLS کو ٹنل نہیں کر سکتے۔ اسے شامل کرنے کے لیے، اوپن سورس ngx_http_proxy_connect_module کے ساتھ nginx کو پیچ اور دوبارہ کمپائل کریں:

git clone https://github.com/chobits/ngx_http_proxy_connect_module
cd nginx-1.27.0
patch -p1 < ../ngx_http_proxy_connect_module/patch/proxy_connect_rewrite_102101.patch
./configure --add-module=../ngx_http_proxy_connect_module
make && make install

پیچ فائل کو اپنے nginx ورژن کے مطابق رکھیں؛ ماڈیول کی ریپازٹری بتاتی ہے کہ کون سا پیچ کس ریلیز کے لیے ہے۔

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

ایک وقف server بلاک بنائیں جو پراکسی پورٹ پر listen کرے، DNS resolver سیٹ کرے، اور ہر درخواست کو اس ہوسٹ تک فارورڈ کرے جو کلائنٹ نے طلب کیا ہے۔ سادہ HTTP سے شروع کریں، پھر HTTPS کے لیے CONNECT ڈائریکٹوز شامل کریں۔

HTTP ٹریفک کے لیے nginx کو فارورڈ پراکسی بنانے کی کم سے کم کنفیگریشن یہ ہے:

server {
    listen 8888;
    resolver 1.1.1.1 ipv6=off;

    location / {
        proxy_pass http://$http_host$request_uri;
        proxy_set_header Host $http_host;
        proxy_buffers 256 4k;
    }
}

resolver کی سطر ضروری ہے کیونکہ nginx درخواست کے وقت متحرک ہدف ہوسٹ کو resolve کرتا ہے۔ اب اسی بلاک کو بڑھا کر CONNECT طریقے سے HTTPS کو ٹنل کریں۔ nginx فارورڈ پراکسی کی یہ HTTPS مثال CONNECT کو فعال کرتی ہے اور اسے معیاری TLS پورٹس تک محدود رکھتی ہے:

server {
    listen 8888;
    resolver 1.1.1.1 ipv6=off;

    proxy_connect;
    proxy_connect_allow            443 563;
    proxy_connect_connect_timeout  10s;
    proxy_connect_read_timeout     10s;
    proxy_connect_send_timeout     10s;

    location / {
        proxy_pass http://$http_host$request_uri;
        proxy_set_header Host $http_host;
    }
}

ایک کھلی فارورڈ پراکسی ایک خطرہ ہے، اس لیے اسے معلوم کلائنٹس تک محدود کریں۔ IP کے ذریعے allow لسٹ بنانا سب سے آسان کنٹرول ہے:

location / {
    allow 198.51.100.0/24;
    deny  all;
    proxy_pass http://$http_host$request_uri;
}

IP قواعد کے بجائے اسناد پر مبنی رسائی کے لیے nginx کے ساتھ تصدیق کی پرت لگائیں؛ ہماری پراکسی تصدیق گائیڈ صارف نام اور پاس ورڈ کے طریقہ اور اس کے پیچھے موجود HTTP 407 ہینڈ شیک کا احاطہ کرتی ہے۔

کیسے تصدیق کریں کہ nginx فارورڈ پراکسی کام کرتی ہے اور عام غلطیاں کیسے درست کریں؟

-x فلیگ کے ساتھ curl کو پراکسی کے ذریعے چلائیں اور کسی IP ایکو سروس کی درخواست کریں؛ اگر جواب میں پراکسی سرور کا عوامی IP دکھائی دے تو تصدیق ہو جاتی ہے کہ ٹریفک اسی سے گزر رہی ہے۔ HTTP اور HTTPS کو الگ الگ جانچیں۔

curl -x http://203.0.113.10:8888 http://httpbin.org/ip
curl -x http://203.0.113.10:8888 https://httpbin.org/ip

ایک لاگ فارمیٹ شامل کریں تاکہ ڈیبگنگ کے دوران ہر فارورڈ شدہ درخواست اور اس کا upstream ہدف دیکھا جا سکے:

log_format proxy '$remote_addr [$time_local] '
                 '"$request" $status $body_bytes_sent '
                 'upstream=$upstream_addr';
access_log /var/log/nginx/forward_proxy.log proxy;

جب کوئی ٹیسٹ ناکام ہو، تو معمول کی وجوہات پر غور کریں:

• HTTPS 400 واپس کرتا ہے یا اٹک جاتا ہے۔ CONNECT ماڈیول کمپائل نہیں ہوا، یا proxy_connect غائب ہے۔ nginx -V دوبارہ چیک کریں۔
• 502 یا ریزولیوشن کی غلطیاں۔ resolver ڈائریکٹو موجود نہیں یا کسی ناقابل رسائی DNS سرور کی طرف اشارہ کرتا ہے۔
• اجازت یافتہ کلائنٹس کے لیے 403۔ درخواست کرنے والا IP آپ کی allow رینج سے باہر ہے۔
• 407 Proxy Authentication Required۔ کوئی upstream اسناد کی توقع کرتا ہے؛ دیکھیں HTTP غلطی 407۔

nginx کو ریزیڈنشل پراکسی پول سے کیسے جوڑیں؟

nginx کو upstream پراکسی سے جوڑنے کے لیے اس کی ٹریفک ایسے ریزیڈنشل گیٹ وے کی طرف فارورڈ کریں جس میں Proxy-Authorization ہیڈر شامل ہو۔ یہی وہ ربط ہے جو ایک جامد سرور IP کو حقیقی IP کے روٹیٹنگ پول تک رسائی دے دیتا ہے۔

اس ڈیزائن کو ایک 3 پرتوں والی پراکسی ٹوپولوجی سمجھیں، جہاں پرتوں کو نام دینے سے اعتماد اور روٹیشن کی حدیں واضح رہتی ہیں:

• پرت 1، کلائنٹ۔ آپ کا اسکرپٹ یا براؤزر، جو nginx استعمال کرنے کے لیے -x کے ساتھ ترتیب دیا گیا ہے۔
• پرت 2، nginx فارورڈ پراکسی: آپ کے اپنے ایک IP پر مرکزی کنٹرول، لاگنگ، اور رسائی کے قواعد۔
• پرت 3، ریزیڈنشل پول۔ بہت سے حقیقی IP پر روٹیشن اور جیو ٹارگٹنگ، جو nginx خود سے فراہم نہیں کر سکتا۔

ریزیڈنشل پراکسیز گیٹ وے کو بھیجنے کی کم سے کم مثال کچھ یوں ہے، جہاں Basic ٹوکن آپ کے login:password کی base64 انکوڈنگ ہے:

server {
    listen 8890;

    location / {
        proxy_pass http://gw.dataimpulse.com:823;
        proxy_set_header Proxy-Authorization "Basic bG9naW46cGFzc3dvcmQ=";
        proxy_set_header Host $http_host;
    }
}

عملی توازن کو ذہن میں رکھیں: خالص روٹیشن کے لیے، اپنے کلائنٹ کو سیدھا gw.dataimpulse.com:823 کے ذریعے چلانا ایک nginx ہاپ شامل کرنے سے آسان ہے۔ جوڑا ہوا سیٹ اپ صرف تب معنی رکھتا ہے جب آپ مرکزی لاگنگ، کیشنگ، یا ٹیم بھر میں مشترکہ رسائی کنٹرول کے لیے nginx کو بیچ میں چاہتے ہیں۔

آپ کے کام کے لیے کون سا پراکسی سیٹ اپ بہتر ہے؟

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

فیصلے کا سادہ خلاصہ یہ ہے:

• اکیلی nginx فارورڈ پراکسی تب استعمال کریں جب آپ باہر جانے والی ٹریفک کو ایک جگہ جمع کر رہے ہوں، درخواستوں کو فلٹر یا لاگ کر رہے ہوں، یا کسی اندرونی ٹیم بھر میں ایک ہی egress IP استعمال کروا رہے ہوں۔
• صرف nginx سے اس وقت گریز کریں جب کوئی ہدف IP کے ذریعے rate-limit یا بلاک کرتا ہو، یا جب آپ کو درخواستیں کئی ممالک سے آنی چاہئیں؛ nginx ایک ہی سرور IP سے فارورڈ کرتا ہے اور روٹیٹ نہیں کر سکتا۔

نیچے دونوں آپشنز کا ساتھ ساتھ موازنہ ہے۔

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

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

nginx فارورڈ پراکسی کی حقیقی حدود ہیں: یہ ایک ہی IP سے فارورڈ کرتی ہے، HTTPS سپورٹ اس میں پہلے سے موجود نہیں ہوتی، اور کھلی انسٹینس سیکیورٹی خطرہ بن سکتی ہے۔ ان حدود کو سمجھنا توقعات کو حقیقت پسندانہ رکھتا ہے۔

• ایک IP، کوئی روٹیشن نہیں۔ ہر درخواست اسی سرور ایڈریس سے نکلتی ہے، اس لیے کوئی بھی ہدف جو IP کے ذریعے محدود کرتا ہے آپ کی رفتار جلد کم کر دے گا یا آپ کو بین کر دے گا۔
• HTTPS کے لیے کسٹم بلڈ درکار ہے۔ CONNECT ٹنلنگ ایک فریق ثالث ماڈیول اور ورژن سے میل کھاتے پیچ پر منحصر ہے، جس سے اپ گریڈ پیچیدہ ہو جاتے ہیں۔
• کھلی پراکسی کا خطرہ۔ allow قواعد یا تصدیق کے بغیر، جو کوئی بھی پورٹ ڈھونڈ لے آپ کے سرور کے ذریعے ٹریفک روٹ کر سکتا ہے، جو آپ کو غلط استعمال اور قانونی خطرے سے دوچار کرتا ہے۔
• کوئی جیو کوریج نہیں۔ exit مقام وہی رہتا ہے جہاں سرور چلتا ہے، اس لیے علاقہ مخصوص ٹیسٹنگ کے لیے مزید سرورز درکار ہوتے ہیں، اور تمام پیچنگ، نگرانی، اور اپ ٹائم آپ کے ذمے ہوتا ہے۔

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

اکثر پوچھے جانے والے سوالات

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

• NGINX ریورس پراکسی
• Scrapy میں روٹیٹنگ پراکسیز
• پراکسیز کی قیمت کتنی ہے

ایسی روٹیشن چاہیے جو nginx فراہم نہیں کر سکتا؟

جب ایک سرور IP کافی نہ ہو تو DataImpulse 195 ممالک میں 9 کروڑ سے زائد روٹیٹنگ ریزیڈنشل، موبائل، اور ڈیٹا سینٹر IP فراہم کرتا ہے۔ ادائیگی بمطابق استعمال 1 ڈالر فی GB سے شروع ہوتی ہے اور ٹریفک ختم نہیں ہوتی۔ گیٹ وے اسناد حاصل کرنے اور اپنے nginx یا کلائنٹ کو براہ راست پول کے ذریعے چلانے کے لیے ایک اکاؤنٹ بنائیں۔