WRONG_VERSION_NUMBER с прокси: проверьте HTTP и HTTPS

Ошибка говорит “неверная версия”, поэтому хочется начать перебирать версии TLS. С прокси проверьте более раннюю возможность: не отправил ли клиент рукопожатие TLS на порт, ожидавший обычный HTTP?

Назначение вроде https://example.com/ и прокси вроде http://proxy.example:8080 — обычная пара. Смена второго URL на HTTPS говорит клиенту шифровать разговор с самим прокси. Это не указание разрешать сайты HTTPS.

Найдите первый разговор TLS

При прокси HTTP клиент может сначала отправить CONNECT и получить ответ HTTP. Только после этого он запускает TLS назначения внутри туннеля. При прокси HTTPS сначала идёт отдельное соединение TLS с прокси.

Анализатор TLS, получивший страницу ошибки HTTP или другой обычный текст, может сообщить об ошибке протокола. Формулировка не устанавливает, какие версии TLS поддерживает сайт, и даже то, что с сайтом связались.

1. Запишите URL прокси, включая схему, и документированный протокол конечной точки.
2. Выясните, произошёл ли сбой до ответа CONNECT, во время TLS назначения или при проверке собственного сертификата прокси.
3. При сравнении старого обходного решения проверьте фактические версии клиента и зависимостей. Ранние реализации прокси иногда трактовали схему иначе.

Несколько исправлений могут быть неверными по разным причинам. Список прокси HTTP предлагает обычные кандидаты конечных точек HTTP для публичных запросов, разрешённых таким путём. Обычной конечной точке HTTP нужна схема прокси HTTP; по-настоящему TLS-включённая конечная точка должна сохранять HTTPS и проверку сертификата. Прокси, отклоняющему CONNECT, нужна поддерживаемая служба или политика, а не произвольное понижение библиотеки.

Сохраняйте первый наблюдаемый сбой. Отключение проверки сертификата не заставит слушателя только с HTTP заговорить на TLS, а выбор старой политики шифров не объяснит отказ HTTP, отправленный до рукопожатия сайта.