مرورگر وصل است اما برنامه‌ها پروکسی نیستند — راهنمای Clash

پروکسی سیستمی یک پیشنهاد است، نه دستور

وقتی کلید پروکسی سیستمی را می‌زنید، کلاینت دقیقاً یک کار می‌کند: 127.0.0.1 و شماره درگاه را در تنظیمات پروکسی سیستم‌عامل می‌نویسد. اینکه کدام برنامه زحمت خواندن آن تنظیم را به خود بدهد دست سیستم‌عامل نیست و نمی‌تواند مجبورش کند. هر که بخواند از پروکسی رد می‌شود، هر که نخواند مستقیم بیرون می‌رود. تمام دلیل اینکه مرورگرتان سالم است و یک برنامه خاص کار نمی‌کند همین است.

Chrome و Edge بدون تنظیم اضافه از تنظیم سیستم پیروی می‌کنند.
Firefox هم به‌طور پیش‌فرض پیروی می‌کند ولی صفحه پروکسی مستقل خودش را دارد. اگر کسی آن را روی پیکربندی دستی یا بدون پروکسی گذاشته باشد، دیگر پیروی نمی‌کند.
ابزارهای خط فرمان کلاً پروکسی سیستمی را نادیده می‌گیرند. curl، git، npm، pip، apt و هم‌خانواده‌هایشان فقط متغیر محیطی می‌شناسند.
بعضی برنامه‌های Electron و بیشتر کلاینت‌های بازی از ابتدا مستقیم وصل می‌شوند، یا فیلد پروکسی خودشان را دارند که ربطی به فیلد سیستم ندارد.
برنامه‌های فروشگاه ویندوز (UWP) داخل یک کانتینر با قواعد جداسازی شبکه اجرا می‌شوند و حکایتشان جداست.

اول تعیین کنید: از پروکسی رد نمی‌شود، یا رد می‌شود و شکست می‌خورد؟

صفحه اتصال‌های کلاینت را باز کنید؛ در بیشتر نسخه‌ها نامش Connections است.
فهرست موجود را پاک کنید، بعد سراغ برنامه بروید و وادارش کنید یک درخواست بفرستد.
حتی یک سطر تازه هم اضافه نشد: برنامه اصلاً از پروکسی استفاده نمی‌کند و دو بخش بعدی مال شماست.
سطرها می‌آیند ولی مدام شکست می‌خورند یا روی چند صد بایت متوقف می‌مانند: برنامه از پروکسی رد می‌شود و مشکل گره یا قوانین است. مسیر بررسی کاملاً فرق می‌کند؛ وقت را روی تنظیمات پروکسی نگذارید.

اگر خود برنامه فیلد پروکسی دارد، همان را پر کنید

ساده‌ترین لایه است و بیشتر از همه هم نادیده گرفته می‌شود. تنظیمات برنامه را بگردید؛ فیلد پروکسی بیشتر از آنچه فکر کنید زیر بخش شبکه یا اتصال پنهان است. 127.0.0.1 و درگاه ترکیبی خود را بنویسید. دقت کنید پروکسی HTTP می‌خواهد یا SOCKS5: mixed-port هر دو را می‌پذیرد پس هر کدام کار می‌کند، ولی در پیکربندی قدیمی که port و socks-port جدا هستند باید همان درست را بدهید.

ابزار خط فرمان فقط متغیر محیطی می‌خواند

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export all_proxy=socks5://127.0.0.1:7890
export no_proxy=localhost,127.0.0.1,::1,192.168.0.0/16

هم نگارش با حروف کوچک و هم با حروف بزرگ بین برنامه‌ها رایج است، پس کار محتاطانه این است که هر نام را دو بار تنظیم کنید. no_proxy نشانی‌های محلی و شبکه داخلی را بیرون نگه می‌دارد؛ اگر جا بیفتد، درخواست به خود دستگاه هم یک دور اضافه می‌زند. این خط‌ها فقط برای همین نشست shell معتبرند و با بستن ترمینال از بین می‌روند — برای ماندگاری آن‌ها را در .bashrc یا .zshrc بگذارید. در ویندوز، PowerShell از شکل $env:HTTP_PROXY استفاده می‌کند، CMD از set، و setx آن را دائمی می‌نویسد. یک نکته دیگر: git و npm و pip هرکدام تنظیم پروکسی مخصوص خود دارند، پس اگر متغیر محیطی نادیده گرفته شد سراغ فایل پیکربندی آن‌ها بروید.

وقتی هیچ‌کدام جواب نداد، فقط TUN می‌ماند

بعضی برنامه‌ها نه فیلد پروکسی دارند و نه به متغیر محیطی اهمیت می‌دهند؛ سوکت باز می‌کنند و می‌روند. با آن‌ها نمی‌شود بحث کرد. TUN یک لایه پایین‌تر کنترل را می‌گیرد: کارت شبکه مجازی می‌سازد و مسیریابی را طوری بازنویسی می‌کند که ترافیک خروجی صرف‌نظر از تصور برنامه‌ها گرفته شود. تنها راه‌حل همه‌منظوره همین است و بهایش دسترسی مدیر و یک دسته مشکل مخصوص خودش است. ترافیک UDP هم همین‌طور است — بازی و تماس صوتی روی UDP می‌روند و پروکسی سیستمی هرگز به آن‌ها دست نزده. نیاز برعکس هم هست: ابزار داخلی، دانلود منیجر و نرم‌افزار اداری که ترجیح می‌دهید از پروکسی رد نشوند. یک قانون بر اساس نام پردازه این را حل می‌کند.

rules:
  - PROCESS-NAME,aria2c.exe,DIRECT
  - PROCESS-NAME,ssh,DIRECT
  - MATCH,PROXY

متغیرهای محیطی گذشته را اصلاح نمی‌کنند. ترمینال را دوباره باز کنید و هر برنامه گرافیکی را کامل ببندید و از نو اجرا کنید — بستن پنجره از نوار وظیفه معمولاً فقط پنهانش می‌کند، پردازه زنده است و همان محیط قدیمی را در دست دارد. خیلی‌ها متغیر را عوض می‌کنند، بلافاصله تست می‌گیرند، تفاوتی نمی‌بینند و نتیجه می‌گیرند روش اشتباه بوده.