چرا برخی وب‌سایت‌ها فقط وقتی VPN روشن است شکست می‌خورند؟

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

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

بگذارید پیام خطا شاخه را انتخاب کند

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

هشدارهای گواهی به شاخه چهارم تعلق دارند. یعنی اتصال را چیزی پاسخ داده که مرورگر نتوانست هویت آن را تأیید کند، یا یک واسط در طرف شما یا یک ناسازگاری واقعی که نباید با کلیک از آن گذشت. با آن مانند یک مسئله اعتماد رفتار کنید، نه مسئله مسیریابی.

سایتی که پاسخ می‌دهد تونل خراب را ثابت نکرده

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

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

وقتی فقط انتقال‌های بزرگ می‌مانند، اندازه بسته را ببینید

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

آن فرضیه را با پیمایش اندازه‌ها به جای یک ping بیازمایید. خرابی‌ای که در اندازه بار ثابتی آغاز می‌شود شاهد قوی است، اما خرابی‌ای که جابه‌جا می‌شود چنین نیست.

اصلاح را روی همان درخواستی که شکست خورد تأیید کنید

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

dig +short www.example.com
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://www.example.com/
curl -sS -o /dev/null -w '%{http_code} %{size_download}\n' https://www.example.com/assets/app.js
ping -M do -s 1400 -c 3 203.0.113.20

اگر پاسخ dig با آنچه مرورگر استفاده کرد متفاوت است، حل‌کننده متغیر است و تنظیم DNS خود مرورگر جایی است که باید نگاه کرد. اگر درخواست کوچک وضعیتی برمی‌گرداند در حالی که بزرگ می‌ماند، شاخه اندازه بسته را کار کنید. اگر هر دو مهلتشان تمام شود، مسیر خروج و برخورد سایت با آن نشانی دوباره روی میز است.

تغییری را که درخواست اصلی را موفق کرد نگه دارید و بقیه را برگردانید. انبوهی از تغییرات همزمان در مرورگر، حل‌کننده و کلاینت نمی‌گذارد بگویید کدام مهم بود.