تونل شما برپاست، صفحه وضعیت یک دست‌دادن سالم نشان می‌دهد، اما یک برنامه هنوز هیچ چیزی بارگذاری نمی‌کند. آن برنامه احتمالاً هنوز درخواست‌هایش را به یک واسطه قدیمی‌تر می‌فرستد: یک پروکسی سیستمی، یک افزونه، یک فایل پیکربندی که مدیریت دستگاه آن را هل می‌دهد، یا یک متغیر پروکسی که تنها پردازه خودش آن را می‌خواند. تغییر سرور 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"

اگر مقدار قدیمی پس از راه‌اندازی دوباره برگشت، منبع یک سیاست مدیریت‌شده یا نمایه‌ای است که آن را دوباره اعمال می‌کند و مالک آن سیاست باید استثنا را بردارد. بررسی گواهی‌ها را در تمام مدت فعال نگه دارید، چون پروکسی‌ای که ترافیک را رهگیری می‌کند وگرنه به محض خاموش کردن بررسی‌ها حل‌شده به نظر می‌رسد. در پایان مقدار حذف‌شده و تاریخ را در یادداشت‌هایتان بنویسید تا نفر بعدی بتواند پروکسی عمدی را از فراموش‌شده تشخیص دهد.

مقالات مرتبط