پروکسی سیستمی چیست و چه محدودیتهایی دارد؟
فهرست مطلب
در هر کلاینت Clash کلیدی بهنام «پروکسی سیستمی» وجود دارد و بیشتر کاربران بدون اینکه بدانند دقیقاً چه میکند آن را روشن میکنند. فهمیدن کارکردش ارزش دارد، چون توضیح میدهد چرا مرورگر شما بدون مشکل کار میکند اما یک بازی یا ابزار خط فرمان همچنان به اینترنت وصل نمیشود.
خلاصه ماجرا: پروکسی سیستمی یک اعلان در سطح سیستمعامل است، نه یک سد. سیستم به برنامهها میگوید «اگر خواستی به اینترنت وصل شوی، از این آدرس و پورت رد شو»، و برنامهها آزادند این توصیه را بخوانند یا نادیده بگیرند. تقریباً همه محدودیتهای این حالت از همین جمله بیرون میآید.
در ادامه میبینیم پروکسی سیستمی روی هر سیستمعامل چطور تنظیم میشود، چه ترافیکی از آن عبور میکند، برای برنامههای خط فرمان چه باید کرد و چه زمانی باید سراغ گزینه سنگینتر یعنی TUN رفت.
پروکسی سیستمی دقیقاً چیست؟
سیستمعامل جایی برای نگهداری نشانی پروکسی دارد؛ در ویندوز بخشی از تنظیمات اینترنت است، در macOS در تنظیمات شبکه هر رابط ذخیره میشود و در دسکتاپهای لینوکس معمولاً محیط دسکتاپ آن را نگه میدارد. کلاینت شما هنگام روشن کردن این کلید، همان مقدار را مینویسد و هنگام خاموش کردن پاکش میکند.
مقداری که نوشته میشود چیزی شبیه 127.0.0.1 بههمراه پورت محلی هسته است؛ یعنی ترافیک از دستگاه شما بیرون نمیرود مگر پس از عبور از mihomo که آنوقت بر اساس قواعد مسیریابی تصمیم میگیرد هر درخواست کجا برود. شماره پورت را در تنظیمات کلاینت ببینید (معمولاً 7890 یا 7897).
چه ترافیکی از آن عبور میکند و چه ترافیکی نه
| دسته | رفتار معمول |
|---|---|
| مرورگرها | تنظیم سیستم را میخوانند و از پروکسی عبور میکنند |
| برنامههای دسکتاپ متداول | در بیشتر موارد پیروی میکنند |
| بازیها و کلاینتهای اختصاصی | اغلب تنظیم سیستم را نمیخوانند |
| ابزارهای خط فرمان | معمولاً فقط با متغیرهای محیطی کار میکنند |
| ترافیک UDP و پروتکلهای غیر HTTP | از این مسیر پشتیبانی نمیشود |
الگو روشن است: هرچه برنامه «وبمحورتر» باشد، احتمال پیرویاش بیشتر است. اگر برنامهای شبکه را با پروتکل خودش و مستقیم صدا بزند، پروکسی سیستمی برایش وجود خارجی ندارد؛ نه خطایی میدهد و نه هشداری، فقط از تونل رد نمیشود.
برنامههای خط فرمان و متغیرهای محیطی
ابزارهایی مثل curl، git، npm و pip تنظیم سیستم را نمیخوانند اما تقریباً همهشان متغیرهای محیطی استاندارد را میشناسند. در لینوکس و macOS:
export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
curl -I https://www.example.comدر PowerShell ویندوز همین کار به این شکل انجام میشود:
$env:http_proxy="http://127.0.0.1:7890"
$env:https_proxy="http://127.0.0.1:7890"این متغیرها فقط برای همان جلسه ترمینال معتبرند و با بستن پنجره از بین میروند. اگر میخواهید دائمی باشند باید به فایل راهاندازی پوسته یا متغیرهای محیطی کاربر اضافهشان کنید — که همیشه ایده خوبی نیست، چون فراموش کردن آنها بعد از خاموش کردن پروکسی به خطاهای گیجکننده منجر میشود.
ترفند: برخی کلاینتها دکمهای برای کپی کردن همین دستورها با پورت درست دارند؛ بهجای تایپ دستی از آن استفاده کنید تا شماره پورت را اشتباه ننویسید.
حالت PAC به زبان ساده
بهجای فرستادن همهچیز به یک آدرس ثابت، میتوان به سیستمعامل نشانی یک اسکریپت کوچک داد که برای هر درخواست تصمیم میگیرد: مستقیم یا از پروکسی. به این روش PAC میگویند و در کلاینتها معمولاً کنار حالت عادی بهعنوان یک گزینه دیده میشود.
در عمل بیشتر کاربران به آن نیازی ندارند، چون تفکیک ترافیک را میتوان با قواعد داخل خود mihomo و بهشکل دقیقتری انجام داد. PAC وقتی مفید است که بخواهید تصمیمگیری در سطح سیستم انجام شود، مثلاً در محیطهای سازمانی. ضمناً پشتیبانی مرورگرها و سیستمها از PAC یکدست نیست، پس اگر رفتار عجیبی دیدید اول به حالت ساده برگردید.
محدودیتها و اینکه کِی به TUN نیاز دارید
جمعبندی محدودیتها کوتاه است: پوشش ناقص چون پیروی داوطلبانه است، ناتوانی در پوشش UDP و پروتکلهای غیر HTTP، و باقی ماندن تنظیمات در سیستم اگر کلاینت بهدرستی بسته نشود. مورد آخر یکی از رایجترین دلایل «اینترنت ندارم» بعد از بستن ناگهانی برنامه است؛ در چنین حالتی تنظیمات پروکسی سیستم را دستی بررسی و پاک کنید.
در مقابل، این حالت سبک است، دسترسی مدیر نمیخواهد و برای مرور روزمره کاملاً کافی است. وقتی برنامهای مسیر سیستم را نادیده میگیرد یا به پوشش کامل در لایه شبکه نیاز دارید، نوبت حالت TUN است که با ساختن یک کارت شبکه مجازی همه ترافیک را بدون رضایت برنامهها در دست میگیرد. برای انتخاب میان این دو، مقایسه TUN و پروکسی سیستمی تفاوتها را کنار هم میگذارد.