تفسیر وضعیت و کدهای خروج یک پایشگر پراکسی
اجرای فرمان، نتیجه HTTP و اعتبارسنجی گواهی را در یک بررسی وب‌سایت از طریق پراکسی جداگانه گزارش کنید.
یک لایه‌پوش نمی‌تواند کد خروج صفر دانلودگر را به «HTTP 200 OK» مشاهده‌شده تبدیل کند. ثبت کنید هر لایه واقعاً چه چیزی گزارش داد:
| میدان | پرسشی که پاسخ می‌دهد |
|---|---|
| خروج ابزار یا افزونه | آیا بررسی اجرا شد و کدام دسته خطا را گزارش کرد؟ |
| مذاکره پراکسی | آیا ارسال یا تونل درخواستی پذیرفته شد؟ |
| وضعیت مبدأ و محتوای مورد انتظار | آیا برنامه نتیجه مورد نظر را برگرداند؟ |
| اعتبارسنجی TLS | آیا بررسی‌های هویتی پیکربندی‌شده موفق بودند؟ |
curl معمولاً می‌تواند پس از پاسخ خطای HTTP صفر برگرداند. گزینه‌های fail آن رفتار خروج را تغییر می‌دهند، اما خروج خطا هنوز وضعیت را یکتا مشخص نمی‌کند. مقادیر خروج Wget هم دسته‌بندی‌اند: شکست احراز هویت مقدار اختصاصی برای HTTP 401 نیست، و دسته خطای سرور همه پاسخ‌های درون خود را مشخص نمی‌کند. بررسی‌ای که انتظار 401 دارد باید همان پاسخ را مشاهده کند.
نقطه پایانی پراکسی و نام وب‌سایت را جدا نگه دارید. همتای TCP یک بررسی پراکسی HTTP خود پراکسی است؛ CONNECT مقصد را نام می‌برد که نشست TLS آن سپس درون تونل اجرا می‌شود. در پراکسی HTTPS، اعتماد به پراکسی بیرونی بررسی گواهی دیگری است.
پیش از آنکه یک پرچم SSL را تأیید تلقی کنید، تضمین افزونه را بررسی کنید. Monitoring Plugins ابزار check_http را به سود check_curl کنار می‌گذارد. مستندات check_http هشدار می‌دهد که انتخاب تنها SSL نه نام میزبان را تأیید می‌کند و نه اعتماد به صادرکننده؛ گزینه verify-peer مستند check_curl شامل آن تأیید است.
از مسیر احراز‌شده مورد نظر هم استفاده کنید. کاوشگر پورت می‌تواند سبز بماند در حالی که حساب عملیاتی 407 می‌گیرد. راز آن را از طریق سازوکار مناسب استقرار برسانید و مرحله‌ای را که واقعاً شکست خورده گزارش کنید: تونل رد‌شده ترمیمی متفاوت از وضعیت غیرمنتظره وب‌سایت می‌خواهد.