خرابی‌های DNS در زنجیره پروکسی HTTP: کدام گام نام را حل می‌کند؟
هنگام عیب‌یابی پروکسی پیش‌رو زنجیره‌ای، رسیدن به پروکسی محلی، حل والد و حل وبگاه را از هم جدا کنید.
client → local forward proxy → HTTP parent → websiteبا نامی که شکست می‌خورد شروع کنید، نه با این ادعا که همه DNS متعلق به «پروکسی» است:
| نام مورد نیاز | گامی که باید به آن برسد |
|---|---|
| نقطه پایانی پروکسی محلی | کارخواه |
| نقطه پایانی والد HTTP | پروکسی پیش‌رو محلی |
| نقطه پایانی وبگاه | والد هنگامی که اتصال نهایی را باز می‌کند |
این گام‌ها وقتی نقاط پایانی نام میزبان باشند می‌توانند از حل‌کننده‌های متفاوت استفاده کنند. در HTTPS، پروکسی پیش‌رو می‌تواند میزبان و درگاه مقصد CONNECT را به والد بدهد و والد اتصال نهایی را برقرار کند. کارخواه اصلی لازم نیست نخست وبگاه را حل کند. ارسال ساده HTTP نیز اطلاعات مقصد را به جلو می‌برد.
این وعده‌ای نیست که دقیقاً یک ماشین هر نام را جویا می‌شود. ارزیابی ACL، حافظه پنهان، سیاست و جزئیات پیاده‌سازی می‌توانند جست‌وجوهای بیشتری ایجاد کنند.
وقتی والد در دسترس نیست سیاست جایگزین را بررسی کنید. اگر دسترسی مستقیم مجاز باشد، پروکسی محلی می‌تواند گام روبه‌روی وبگاه شود، با تصمیم‌های خودش برای حل‌کننده و نشانی مبدأ. تنها پیکربندی والد ثابت نمی‌کند که هر درخواست از آن استفاده کرده است.
در بروز خرابی، پیش از ویرایش فایل hosts نام و فرایندی را که می‌کوشد آن را حل کند شناسایی کنید. ویرایش سمت کارخواه نمی‌تواند همه تصمیم‌های پایین‌دست را ترمیم کند. منبع عمومی نهایی متعلق به گامی است که اتصال وبگاه را باز می‌کند؛ مشاهده آن منبع با اندازه‌گیری اینکه DNS کجا رخ داده یکی نیست.