HTTP и SOCKS5 прокси: выбирайте по типу соединения

С чего начать

Выбирайте протокол прокси независимо от типа исходящего IP-адреса. Метка HTTP или SOCKS не говорит о том, мобильный это выход или резидентный.

Начните с клиента и целевого сервера

HTTP-прокси понимает HTTP-запросы. Для HTTPS-назначения обычный подход — CONNECT: прокси устанавливает туннель к целевому хосту и порту, а затем клиент через него согласует TLS с целевым сервером. SOCKS5 согласует ретранслирующее соединение на другом уровне протокола и определяет операции TCP и UDP.

Возможности протокола — не обещание сервиса. Провайдер или клиент SOCKS5 может не реализовывать то поведение UDP, которое нужно вашему приложению. Прежде чем выбирать протокол, подтвердите поддержку конкретной операции, метода аутентификации и целевого порта.

Решите, где выполняется DNS для целевого сервера

В соглашении curl об URL socks5:// разрешает имя целевого сервера локально; socks5h:// отправляет имя целевого хоста прокси для разрешения. От этого зависит, какой резолвер видит запрос и какой адрес он возвращает. Имя самого шлюза по-прежнему должен разрешать ваш клиент.

Для регионального QA-теста фиксируйте, где выполнялся DNS, вместе с регионом выхода. Иначе два прогона могут отличаться из-за резолвера, а не из-за сети, которую вы хотели сравнить. Переключение на удалённый DNS — контролируемый параметр теста, а не гарантия того, что возвращённый контент относится к конкретному региону.

Обозначьте обе границы TLS

HTTPS-прокси шифрует соединение между клиентом и прокси. HTTPS-назначение шифрует соединение с целевым сервером. Это независимые уровни с независимой проверкой сертификатов. Обычный HTTP-шлюз может туннелировать HTTPS-назначение, но его собственный обмен аутентификацией при этом не защищён TLS целевого сервера.

Спросите провайдера, предлагает ли он TLS до шлюза и перехватывает ли он TLS целевого сервера. Стандартное туннелирование и инспектирующий корпоративный прокси предъявляют разные требования к доверию. Оставляйте проверку включённой на всех задействованных уровнях TLS.

Проведите небольшой отборочный тест

Для приложения, работающего только с вебом, начните с протокола, который его HTTP-клиент поддерживает без оговорок. Если другому приложению специально требуется SOCKS, проверьте это требование напрямую. Сравните оба варианта на одном и том же разрешённом целевом сайте, прежде чем делать выводы о производительности.

• Может ли клиент аутентифицироваться методом, который использует провайдер?
• Может ли он разрешать имя целевого сервера на нужной стороне соединения?
• Поддерживает ли он требуемые порты и транспорт?
• Может ли ваша команда диагностировать и отслеживать сбои на каждом уровне?

Перед выпуском

• Разделяйте протокол, тип выхода и режим ротации.
• Фиксируйте поведение DNS для целевого сервера.
• Проверяйте TLS и до шлюза, и до целевого сервера там, где это применимо.