پورت TCP باز ثابت نمی‌کند که پروکسی کار می‌کند
موفقیت بررسی پورت فقط اتصال را برقرار می‌کند. دست‌دهی پروکسی و پاسخ مورد انتظار مقصد را هم بررسی کنید.
پورت TCP باز نشان می‌دهد شنونده‌ای یک اتصال را پذیرفته است. ممکن است پروکسی، وب‌سرور معمولی یا سرویس دیگری باشد؛ پورت 8080 پروتکل را مشخص نمی‌کند.
برای نقطه‌ای که به‌عنوان پروکسی HTTP مستند شده، نشانی واقعی را در درخواست HTTPS با محدودیت زمانی به کار ببرید:
curl --proxy http://203.0.113.10:8080 --noproxy '' --connect-timeout 5 --max-time 15 --verbose https://example.com/نشانی مستنداتی را با نقطه HTTP خود یا گزینه‌ای از فهرست پروکسی HTTP عوض کنید. برای SOCKS از حالت مناسب کلاینت SOCKS استفاده کنید و مذاکره را کامل کنید. دست‌دهی نادرست ممکن است بلافاصله پس از پذیرش TCP شکست بخورد.
| مرحله مشاهده‌شده | آنچه ثابت می‌کند |
|---|---|
| TCP پذیرفته شد | شنونده در دسترس است. |
| دست‌دهی پروکسی پذیرفته شد | شنونده این عملیات پروکسی را پذیرفت. |
| TLS مقصد تأیید شد | کلاینت اتصال امن مورد نظر را طبق تنظیمات اعتماد خود کامل کرد. |
| وضعیت و محتوای مورد انتظار دریافت شد | درخواست برنامه نتیجه مورد انتظار را تولید کرد. |
برای HTTPS از طریق پروکسی HTTP، باید CONNECT به پورت مقصد مجاز باشد. حتی CONNECT 200 مرحله‌ای میانی است: تونل ممکن است پیش از موفقیت TLS یا درخواست نهایی بسته شود. موفقیت HTTP بدون رمزگذاری این توانایی تونل را ثابت نمی‌کند.
مقصدی با محتوای قابل پیش‌بینی و ترجیحاً تحت کنترل خود انتخاب کنید و اگر گزارش درخواست آن در دسترس است، بررسی کنید. شنونده HTTP بدون رمزگذاری می‌تواند بدون تماس با هدف، صفحه‌ای ثابت با وضعیت 200 برگرداند. دریافت هر وضعیت موفقی شاهد ضعیف‌تری از مطابقت پاسخ با انتظار است؛ تأیید هویت HTTPS حفاظت بیشتری می‌دهد.
آخرین مرحله موفق را ثبت کنید. «پورت باز، مذاکره SOCKS رد شد» نقطه شروع مفیدی برای بررسی بعدی است.