VPN کام کر رہا ہے، لیکن ایک ایپ میں انٹرنیٹ نہیں؟ اس کا پراکسی چیک کریں

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

پراکسی ترتیب کس پرت کی ملکیت ہے

چار جگہیں کسی ایپ کی درخواستوں پر اختیار کا دعویٰ کر سکتی ہیں، اور عام طور پر سب سے تنگ جیت جاتی ہے۔ آپریٹنگ سسٹم ایک عالمی پراکسی اور ایک اختیاری خودکار کنفیگریشن URL رکھتا ہے؛ براؤزر اس کی پیروی کر سکتا ہے، اسے اوور رائڈ کر سکتا ہے یا کنٹرول کسی ایکسٹینشن کو دے سکتا ہے؛ کمانڈ لائن ٹول اپنا ماحول پڑھتا ہے؛ اور منظم پالیسی تبدیلی کے بعد اوپر کے کسی بھی حصے کو دوبارہ پن کر سکتی ہے۔ کچھ بھی ترمیم کرنے سے پہلے طے کریں کہ کون سی پرت ذمہ دار ہے، کیونکہ غلط پرت صاف کرنا ایک کامیاب مرمت جیسا لگتا ہے جو اگلی لاگ ان پر واپس آ جاتا ہے۔

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

وہ قدر پڑھیں جو ہر ٹول واقعی استعمال کرتا ہے

تبدیلی سے پہلے کنفیگریشن پرنٹ کریں، اور درست پراکسی اسٹرنگ کو ایسی جگہ کاپی کریں جہاں سے آپ اسے بحال کر سکیں۔ شیل متغیرات کمانڈ لائن ٹولز کے لیے سب سے تیز جانچ ہیں، کیونکہ VPN کلائنٹ عام طور پر انہیں اچھوتا چھوڑ دیتا ہے۔

env | grep -i -E 'http_proxy|https_proxy|all_proxy|no_proxy'
scutil --proxy
gsettings get org.gnome.system.proxy mode
netsh winhttp show proxy

صرف وہی سطر چلائیں جو آپ کے سامنے کے پلیٹ فارم سے مطابقت رکھتی ہے، پھر ہوسٹ، پورٹ اور اسناد کے لیے آؤٹ پٹ پڑھیں۔ ایسی قدر http://proxy.corp.example:8080 کا مطلب ہے کہ ٹول ہر درخواست کے لیے اس ہوسٹ سے پوچھتا ہے، جبکہ خالی نتیجہ کا مطلب ہے کہ وہ سیدھا جاتا ہے اور اصل خرابی کہیں اور ہے۔ آؤٹ پٹ کو ٹکٹ میں چسپاں کرنے سے پہلے صارف اور پاس ورڈ والا حصہ چھپائیں، کیونکہ وہ اسٹرنگیں لوگوں کے اندازے سے کہیں زیادہ بار زندہ اسناد ہوتی ہیں۔

جن ٹولز کا اپنا پراکسی انجن ہے انہیں اپنے ثبوت چاہیے۔ جب آپ تفصیل بڑھاتے ہیں تو Curl اپنا کیا ہوا فیصلہ بتاتا ہے، جو ماحول سے اندازہ لگانے سے بہتر ہے، اور وہی جھنڈا دکھاتا ہے کہ ناموں کا حل مقامی طور پر ہوا یا پراکسی پر۔

اوور رائڈ صاف کریں اور وہی درخواست دوبارہ جانچیں

ایک پرت بدلیں، پھر بالکل وہی درخواست دہرائیں جو ناکام ہوئی تھی، کیونکہ کوئی دوسرا URL کچھ ثابت نہیں کرتا۔ پہلے موجودہ شیل میں ماحول کے متغیرات صاف کریں، کیونکہ وہ ترمیم واپس ہو سکتی ہے اور ٹنل کو توڑ نہیں سکتی:

unset http_proxy https_proxy all_proxy
curl -v --max-time 10 https://example.com 2>&1 | grep -i -E 'uses proxy|connected to|http/'

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

macOS پر جانچیں کہ خودکار کنفیگریشن فائل قدر فراہم نہیں کر رہی، پھر سروس پراکسی بند کریں اور تبدیلی کی تصدیق کریں۔ Windows پر یاد رکھیں کہ WinHTTP ترتیب اور فی صارف براؤزر ترتیب الگ الگ اشیاء ہیں، اس لیے ایک صاف کمانڈ لائن ٹول ایسے براؤزر کے ساتھ رہ سکتا ہے جو اب بھی پرانے سرور کی طرف اشارہ کرتا ہے۔ ایکسٹینشنز بھی اسی شک کے لائق ہیں: پراکسی ایکسٹینشن صرف ایک پروفائل کے لیے درخواستیں دوبارہ لکھ سکتی ہے، اور یہ بالکل اس خرابی کی شکل ہے جو ایک براؤزر کو متاثر کرتی ہے اور کسی اور کو نہیں۔

تصدیق کریں کہ مرمت ری اسٹارٹ کے بعد بھی قائم رہتی ہے

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

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

env -i /usr/bin/curl -sS -o /dev/null -w '%{http_code} %{remote_ip}
' https://example.com
networksetup -getwebproxy "Wi-Fi"

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