proxy_redirect NGINX کو آپ کے VPN ہوسٹ سے نہیں جوڑتا
proxy_redirect پہلے ہی آ چکے جواب میں ہیڈر دوبارہ لکھتا ہے؛ یہ کبھی upstream منتخب نہیں کرتا۔ proxy_pass، backend تک راستہ، پھر ہیڈر جانچیں۔
نام میں redirect کا لفظ ہے، اس لیے جب VPN کے پیچھے موجود backend قابل رسائی نہ ہو تو اسے location بلاک میں چپکا دیا جاتا ہے۔ کچھ نہیں بدلتا، اور واضح نتیجہ یہ ہے کہ ہدایت ٹوٹی ہوئی ہے یا مختلف نحو درکار ہے۔ دراصل جو ہوا وہ زیادہ سادہ اور کم قابلِ تعریف ہے: proxy_redirect پہلے ہی واپس آ چکے جواب پر کام کرتا ہے، اور اس تعیناتی میں کوئی درخواست اتنی دور تک نہیں پہنچی۔
ایک درخواست میں دو ہدایات، دو لمحے
ریورس پراکسی سے گزرنے والی HTTP درخواست ترتیب سے کئی فیصلوں سے گزرتی ہے، اور دونوں ہدایات اس ترتیب کے مخالف سروں پر ہوتی ہیں۔ ایک طے کرتی ہے کہ درخواست کہاں جائے گی۔ دوسری واپس آنے والے جواب میں کچھ ہیڈر ترمیم کرتی ہے۔
| Directive | When it acts | What it can change |
|---|---|---|
proxy_pass | Before any bytes leave the proxy | Which upstream receives the request |
proxy_redirect | After the upstream responds | Matching Location and Refresh text |
یہی ترتیب پورا جواب ہے۔ اگر پہلی سطر ناکام ہونے کی وجہ سے دوسری سطر کبھی نہ چلے، تو دوسری ہدایت غلط ترتیب نہیں دی گئی، وہ محض ناقابلِ رسائی ہے۔ دوسری سطر کو جتنا بھی دوبارہ لکھیں، وہ جواب جسے ترمیم کرنا تھا وجود میں نہیں آئے گا۔ پہلی سطر سے باہر کی طرف تشخیص کریں، اور الجھن والا رویہ گمشدہ راستے یا مسترد شدہ کنکشن میں بدل جاتا ہے۔
upstream کا انتخاب proxy_pass کا کام ہے
فرض کریں NGINX کسی عوامی داخلے کے host پر چلتا ہے اور اپنے VPN کے ذریعے 10.40.0.20:8080 پر موجود ایپلیکیشن تک پہنچتا ہے۔ اس ایپلیکیشن کو منتخب کرنے والا ٹکڑا موجودہ server بلاک کے اندر ایسا دکھتا ہے:
location / {
proxy_pass http://10.40.0.20:8080;
}اصل اسکیم، پتہ اور پورٹ استعمال کریں، اور اسے تعیناتی نہیں بلکہ ٹکڑا سمجھیں۔ داخلے کے host کو VPN راستہ، اجازت یافتہ فارورڈنگ پاتھ اور اس سروس تک کام کرنے والا واپسی ٹریفک بھی رکھنا ہوتا ہے، کیونکہ کاغذ پر پتے تک پہنچنے والے پراکسی کو بھی کرنل کی رضامندی درکار ہے۔
proxy ماڈیول کا حوالہ upstream کے انتخاب کو جواب کے ہیڈر کی دوبارہ تحریر سے الگ رکھتا ہے، اور بتاتا ہے کہ URI والی proxy_pass قدر یہ بدل دیتی ہے کہ مطابق location سابقہ کیسے بدلا جاتا ہے۔ ایپلیکیشن کے متوقع URL کی جانچ کیے بغیر راستے کے اجزا شامل کرنا یا ہٹانا 404 پیدا کرنے کا بھروسہ مند طریقہ ہے، جو روٹنگ کی ناکامی جیسا لگتا ہے۔
proxy_redirect نجی پتہ ظاہر کرنے والے جوابات درست کرتا ہے
ٹریفک بہنے لگے تو backend اپنا نجی پتہ بتانے والے Location ہیڈر کے ساتھ جواب دے سکتا ہے۔ اس ہیڈر کی پیروی کرنے والا براؤزر عوامی دخول نقطہ چھوڑ دیتا ہے اور ایسی چیز تک پہنچنے کی کوشش کرتا ہے جسے وہ حل نہیں کر سکتا۔ جان بوجھ کر ترتیب دی گئی جواب کی دوبارہ تحریر نجی URL کو عوامی پر نقش کرتی ہے:
proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;دونوں طرف اصل اقدار سے بدلیں۔ تنگ دائرہ بھی سمجھیں: مطابق Location اور Refresh ہیڈر کا متن دوبارہ لکھا جاتا ہے، مگر HTML، JavaScript یا ڈاؤن لوڈ شدہ فائلوں میں شامل URL نہیں۔
اگر ایپلیکیشن ہر جگہ مطلق لنک بناتی ہے، تو پائیدار حل اس کی اپنی بیرونی-URL ترتیب ہے، پراکسی پر بڑھتی ہوئی دوبارہ تحریر کی قواعد کی فہرست نہیں۔ نتیجہ درست دکھنے تک قواعد شامل کرنا ایسی ترتیب بناتا ہے جو پہلے ہی ایسے صفحے پر ناکام ہو جاتی ہے جسے کسی نے جانچا نہیں۔ ایپلیکیشن کی ایک درست ترتیب پورا مجموعہ بدل دیتی ہے۔
ہیڈر کی دوبارہ تحریر کیا درست نہیں کر سکتی
کئی قریبی مسائل ری ڈائریکٹ مسائل جیسے لگتے ہیں مگر نہیں ہیں۔ upstream کو بھیجا جانے والا Host ہیڈر backend کے ورچوئل host سے مطابقت رکھنا چاہیے ہو سکتا ہے۔ TLS upstream کو مخصوص سرور نام اور سرٹیفکیٹ کی تصدیق درکار ہو سکتی ہے، اور جواب کے ہیڈر کی دوبارہ تحریر دونوں میں سے کسی کی مدد نہیں کرتی۔
کوکی کا دائرہ اور ڈومین خصوصیات ایپلیکیشن اور اس کی ترتیب کے ہیں۔ پراکسی سارا دن ہیڈر پھینک یا دوبارہ لکھ سکتا ہے اور پھر بھی ایسا سیشن بنا سکتا ہے جو دوسری درخواست پر ناکام ہو، کیونکہ کوکی ایسے host کے لیے جاری ہوئی تھی جسے براؤزر نے کبھی نہیں دیکھا۔ وہ ناکامی وقفے وقفے سے ہوتی دکھتی ہے، اسی لیے ٹکٹ قطار میں اتنی دیر رہتی ہے۔ کوکی کا ڈومین پڑھنا عام طور پر ایک منٹ میں جانچ ختم کر دیتا ہے۔
تصدیق اور backend کے انتخاب کو بھی مطلوبہ ایپلیکیشن تک محدود رکھیں۔ عوامی ریورس پراکسی کو سرور کے VPN کے ذریعے ایک ہی ایپلیکیشن ظاہر کرنی چاہیے، اس host کی رسائی کے ہر نجی پتے کے لیے عمومی گیٹ وے بننے کے بجائے۔ ایک عمومی location جو کال کرنے والے کی ہر درخواست آگے بھیجتا ہے، ایک ظاہر شدہ سروس کو آپ کے نجی نیٹ ورک کا نقشہ بنا دیتا ہے۔ upstream کا نام واضح دیں اور اسے وہیں رکھیں۔
اسی ترتیب سے جانچیں جس میں درخواست سفر کرتی ہے
ترتیب سے تین چیزیں تصدیق کریں: NGINX نے مطلوبہ location منتخب کیا، backend تک درخواست مکمل کی، اور براؤزر نے بعد کی کوئی بھی ری ڈائریکٹ پیروی کر کے ذیلی وسائل لوڈ کیے۔ ہر مرحلے کی اپنی لاگ سطریں ہیں، اور انہیں ترتیب سے پڑھنا مبہم 502 کو ٹھوس دریافت میں بدل دیتا ہے۔
آپ کو درکار فرق ناکام upstream کنکشن اور ناقابلِ رسائی نجی نام کی طرف بھیجے گئے براؤزر کے درمیان ہے۔ پہلا پراکسی کی خرابی کے لاگ میں نظر آتا ہے؛ دوسرا ایسی درخواست کی صورت میں نظر آتا ہے جو کبھی نہیں آتی، اور براؤزر ایسے host کی شکایت کرتا ہے جسے وہ حل نہیں کر سکتا۔ دو مختلف مسائل، دو مختلف فائلیں، اور ان میں سے صرف ایک کا proxy_redirect سے کوئی تعلق ہے۔