Відкритий 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 відхилено» дає корисну вихідну точку подальшої перевірки.