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

curl --proxy '' --http1.1 --max-time 10 \
  --request CONNECT \
  --request-target service.example:443 \
  --header 'Host: service.example:443' \
  --dump-header tunnel.headers \
  --output tunnel.body \
  http://proxy.example:8080/

نشانی نهایی به شنوندهٔ پروکسی اشاره می‌کند. برای مقایسهٔ مجاز پروکسی‌های عمومی، فهرست پروکسی HTTP نامزدهایی برای آن نشانی شنونده فراهم می‌کند. --request توکن متد را تأمین می‌کند؛ --request-target اختیار CONNECT را تأمین می‌کند. جدا نگه داشتن آن دو CONNECT service.example:443 HTTP/1.1 تولید می‌کند.

گزینهٔ خالی پروکسی مانع می‌شود curl این تشخیص را از طریق پروکسی ارثی دیگری هدایت کند. فرمان عمداً --fail را حذف می‌کند تا سند خطای HTTP قابل نگه‌داشتن باشد.

تلاش بدون احراز هویت ممکن است پیش از رسیدن به شکستی که بررسی می‌شود در 407 متوقف شود. هنگام بازتولید یک درخواست احرازشده از ترتیب احراز هویتی که پروکسی در نظر دارد استفاده کنید.

این برای بررسی پاسخ‌های شکست است. اگر پروکسی 2xx برگرداند، اتصال به یک تونل به‌جای انتقال معمول بدنهٔ HTTP تبدیل می‌شود. این تشخیص با متد سفارشی تبادل TLS مقصد را آغاز نمی‌کند و می‌تواند روی یک تونل باز پذیرفته‌شده به محدودیت زمانی خود برسد.

برای دریافت واقعی HTTPS از جریان عادی درخواست --proxy استفاده کنید. وضعیت و بدنهٔ تشخیص را همراه با پروکسی و هدف مشخص خودشان نگه دارید.

مقالات مرتبط