VPN در برابر پروکسی: هر کدام چه چیزی را پوشش می‌دهد و چه چیزی را نه
VPN ترافیک مسیریابی‌شدهٔ برنامه‌ها را پوشش می‌دهد؛ پروکسی فقط برنامه‌ای را که خودتان پیکربندی می‌کنید. پیش از انتخاب، پوشش، رمزنگاری، DNS و رفتار در زمان خطا را بررسی کنید.
هم VPN و هم پروکسی پیشرو نشانی‌ای را که یک وب‌سایت می‌بیند تغییر می‌دهند، و بیشتر مقایسه‌ها همین‌جا تمام می‌شود. تفاوتی که تنظیمات شما را تعیین می‌کند پوشش است: پروکسی پیشرو واسطه‌ای است که برنامهٔ شما خودش استفاده از آن را انتخاب می‌کند، برخلاف پروکسی معکوس که جلوی یک وب‌سایت می‌نشیند، در حالی که VPN هر چیزی را که سیستم‌عامل به یک تونل مسیریابی می‌کند جابه‌جا می‌کند. رمزنگاری، مدیریت DNS و رفتار در زمان خطا همه از همین تقسیم‌بندی ناشی می‌شوند. این پنج بررسی را به ترتیب اجرا کنید، و اولین بررسی‌ای که شکست بخورد به شما می‌گوید واقعاً به کدام ابزار نیاز دارید.
واسطه کدام برنامه‌ها را پوشش می‌دهد؟
افزونهٔ پروکسی مرورگر فقط برای همان نمایهٔ مرورگر اعمال می‌شود. برنامه‌های ایمیل، مدیران بسته و مرورگر دوم همچنان از تنظیمات خودشان استفاده می‌کنند، و برخی برنامه‌ها متغیرهای پروکسی سیستم را کاملاً نادیده می‌گیرند. VPN آنچه را جدول مسیریابی به تونل می‌فرستد پوشش می‌دهد، که بسته به مسیرها و خط‌مشی کارخواه می‌تواند همهٔ برنامه‌ها یا زیرمجموعه‌ای در تونل تقسیم‌شده باشد.
برنامه‌هایی را که مهم‌اند آزمایش کنید، نه اینکه از یک بار بارگذاری صفحه تعمیم دهید. curl https://ifconfig.me از متغیرهای محیطی پروکسی پیروی می‌کند؛ یک برنامهٔ رومیزی ممکن است پیروی نکند. در Windows، دستور netsh winhttp show proxy پروکسی WinHTTP را که سرویس‌ها استفاده می‌کنند چاپ می‌کند، و این تنظیمی متفاوت از تنظیم مرورگر است.
آیا گام رمزنگاری شده است، و TLS کجا پایان می‌یابد؟
پروتکل پروکسی یک نقطهٔ ملاقات است، نه تضمین. SOCKS5 بدون رمزنگاری TCP را ارسال می‌کند، و پروکسی HTTP ساده خط درخواست و سرآیندها را به‌صورت متن روشن حمل می‌کند. HTTPS از طریق پروکسی از CONNECT استفاده می‌کند، بنابراین نشست TLS شما همچنان در مقصد پایان می‌یابد، نه در پروکسی. راهنمای MDN دربارهٔ سرورهای پروکسی و تونل‌سازی این تفاوت را از سمت پروتکل توضیح می‌دهد.
VPN بخش میان دستگاه شما و نقطهٔ پایانی آن را رمزنگاری می‌کند. فراتر از نقطهٔ پایانی همان قوانین هر شبکهٔ دیگری اعمال می‌شود، و به همین دلیل تونل به‌تنهایی از برنامه‌ای که اعتبارنامه‌ها را از طریق HTTP ساده می‌فرستد محافظت نمی‌کند. هیچ‌کدام از این دو طراحی حساب واردشده، کوکی یا اثر انگشت مرورگر را پنهان نمی‌کند.
curl -v -x http://127.0.0.1:3128 https://example.com/ -o /dev/null
curl -v -x socks5h://127.0.0.1:1080 https://example.com/ -o /dev/nullخروجی مبسوط نشان می‌دهد curl آیا CONNECT را به درگاه 443 فرستاده یا یک GET ساده با URL کامل. با socks5h:// نام میزبان درون درخواست SOCKS5 به پروکسی داده می‌شود و سپس TLSای را که نمی‌تواند بخواند بازپخش می‌کند، پس نام و شمار بایت‌ها را می‌بیند. از طریق پروکسی http://، نشانی https:// یک CONNECT است، پس آن پروکسی هم نام و حجم مقصد را می‌بیند، نه درخواست یا بدنهٔ پاسخ را.
کدام حل‌کننده نام را می‌بیند؟
تفکیک نام می‌تواند به‌صورت محلی پیش از خروج درخواست رخ دهد، یا به‌صورت دور در پروکسی. با curl، socks5h:// نام میزبان را به پروکسی می‌فرستد در حالی که socks5:// ابتدا آن را محلی تفکیک می‌کند. تنظیمات پروکسی مرورگر گزینهٔ DNS مشابهی ارائه می‌دهد، و پرونده‌های PAC می‌توانند میزبان‌های مختلف را به روش‌های مختلف مسیریابی کنند.
دو پروتکل می‌توانند بدون هیچ پیکربندی اشتباهی پروکسی را دور بزنند. WebRTC نامزدها را از طریق STUN جمع می‌کند، و QUIC پروتکل HTTP/3 را روی UDP اجرا می‌کند که یک پروکسی TCP نمی‌تواند حملش کند. مرورگر اگر UDP 443 مسدود باشد به TCP بازمی‌گردد، پس مسدود کردن UDP 443 در فایروال میزبان (یا در روتر برای کل شبکه)، و نه یک پرچم مرورگر، راه مطمئن نگه‌داشتن HTTP/3 در مسیر پروکسی است.
حل‌کننده را از دید مقصد بررسی کنید، نه از دید لپ‌تاپ خودتان. درخواستی که با نشانی خروج پروکسی اما با نامی که محلی تفکیک شده می‌رسد، همچنان به حل‌کنندهٔ محلی می‌گوید از کدام سایت‌ها بازدید می‌کنید.
وقتی واسطه از کار می‌افتد چه می‌شود؟
پروکسی صریح بسته شکست می‌خورد: فرایند پروکسی را متوقف کنید و مرورگر یا برنامه به‌جای رفتن مستقیم خطای اتصال برمی‌گرداند. تنظیمات PAC و WPAD همان‌هایی هستند که باز شکست می‌خورند - اگر اسکریپت واکشی نشود، کارخواه به DIRECT بازمی‌گردد و سایت دوباره نشانی واقعی شما را می‌بیند. VPN بسته به کارخواه و اینکه کلید قطع یا قاعدهٔ فایروال فعال باشد می‌تواند باز یا بسته شکست بخورد.
حالت شکست را عمداً آزمایش کنید: سرویس پروکسی را متوقف کنید و صفحه را دوباره بارگذاری کنید؛ اگر به‌جای بارگذاری مستقیم صفحهٔ خطا گرفتید، نشانی PAC را به میزبانی غیرقابل دسترس نشان دهید تا بازگشت را ببینید. اگر صفحه همچنان از مسیر معمول شما بارگذاری می‌شود، پروکسی هیچ محافظتی در برابر قطعی خودش ندارد، و این ویژگی‌ای است که باید پیش از تکیه بر آن بدانید.
ترتیب تعیین می‌کند سایت چه می‌بیند. پروکسی‌ای که ترافیک خروجی‌اش از VPN می‌گذرد، باعث می‌شود سایت نشانی نقطهٔ پایانی VPN را ببیند؛ پروکسی را بیرون تونل بگذارید (VPN به پروکسی روی میزبان دور) و سایت به‌جای آن نشانی خروج آن پروکسی را می‌بیند. در هر دو حالت دو گام می‌توانند چیزهای متفاوتی ثبت کنند.
پنج بررسی، به ترتیب
فهرست بررسی زیر کل تصمیم را در یک جا دارد. پوشش اول می‌آید چون بیشتر ناهماهنگی‌ها را حذف می‌کند: اگر برنامه‌ای که باید پوشش داده شود به تنظیم احترام نگذارد، هیچ چیز بعدی در فهرست نجاتش نمی‌دهد.
| Check | Forward proxy | VPN |
|---|---|---|
| What is covered | The app or browser you configure | Traffic the OS routes into the tunnel, all or split |
| Encryption scope | Protocol-dependent; SOCKS5 alone encrypts nothing | Device to VPN endpoint |
| DNS path | Local or remote, depending on the setting | Normally inside the tunnel |
| Failure mode | Explicit config: connection error; PAC/WPAD: DIRECT fallback | Client policy: fail-open or kill switch |
| What the site sees | The proxy's exit address | The VPN endpoint's exit address |
سپس نتیجه را با همان برنامه‌ای که تغییر را باعث شد تأیید کنید. صفحه‌ای را در مرورگر پیکربندی‌شده بارگذاری کنید، همان صفحه را با curl واکشی کنید، و نشانی‌ای را که هر کدام گزارش می‌دهد مقایسه کنید. اگر اختلاف داشتند، یک افزونه، یک قاعدهٔ PAC یا بازنویسی در سطح برنامه هنوز در کار است، و هیچ میزان تنظیم تونل آن را درست نمی‌کند.
آنچه را پیکربندی کردید ثبت کنید: کدام برنامه‌ها از پروکسی استفاده می‌کنند، DNS محلی است یا دور، UDP مسدود است یا نه، و رفتار در زمان خطا چیست. همین فهرست کوچک است که مقایسهٔ بعدی را ممکن می‌کند، چون «IP تغییر کرد» هرگز به شما نگفت کدام یک از این پنج بررسی موفق شد.