لماذا تفشل بعض المواقع فقط عند تشغيل 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 الخاص بالمتصفح هو الموضع الذي يجب النظر فيه. إذا أعاد الطلب الصغير حالة بينما توقف الكبير، فاعمل على فرع حجم الحزمة. إذا انتهت مهلة الاثنين، فمسار الخروج وتعامل الموقع مع ذلك العنوان عادا إلى الطاولة.

احتفظ بالتغيير الذي جعل الطلب الأصلي ينجح وأعد الباقي. كومة من التغييرات المتزامنة على المتصفح والمحلل والعميل تمنعك من قول أيها كان مهماً.