При сбое прокси проверяйте три уровня: сначала смену IP и географию выхода, затем отдельно DNS, тайм-аут и сертификаты, а после — аутентификацию, порт и протокол.
Прокси настроен, логин и пароль указаны верно, но проверка всё равно сообщает об ошибке подключения. Многие сразу обращаются к провайдеру прокси, меняют узел, порт или торопят поддержку. Обычно это малоэффективно, потому что причина может находиться в любой точке всей цепочки соединения, а прокси — лишь одно из её звеньев.
Вместо случайных попыток лучше использовать постоянный порядок снаружи внутрь: сначала убедиться, что выход действительно задействован, затем проверить прохождение сетевого пути и только после этого разбирать аутентификацию и протокол на прикладном уровне. Эти три уровня позволяют найти большинство проблем.
Действительно ли работает выход?
Этот шаг легко пропустить, потому что конфигурация выглядит успешной. Но успешная настройка и фактическое прохождение трафика через прокси — разные вещи.
Проверьте два пункта. Первый: изменился ли IP? Запишите публичный IP без прокси, включите прокси и проверьте снова. Если адрес тот же, трафик вообще не выходит через прокси и дальнейшая диагностика бессмысленна. Второй: соответствует ли география? В данных прокси обычно указаны страна, регион, штат или область, город, координаты с точностью до шести знаков после запятой и почтовый индекс. Сверьте их с регионом, который был приобретён. Явное несоответствие системного часового пояса региону выхода — тоже тревожный признак.
Если выход не применяется, причина часто находится в оставшихся локальных настройках, а не у провайдера. Если ранее использованная сетевая программа при завершении не очистила настройки, в системе могут сохраниться переменные окружения вроде HTTP_PROXY или HTTPS_PROXY, а в macOS могут остаться включёнными Web Proxy или SOCKS Proxy. Тогда клиент думает, что использует системный прокси, хотя запросы на деле его обходят. Очистить такие остаточные настройки и повторить тест часто полезнее, чем заново настраивать прокси.
Три типичных ошибки сетевого пути
После подтверждения выхода проверьте, действительно ли запрос достигает цели.
Первой точкой отказа может быть DNS-разрешение. Это проявляется ошибкой разрешения или явно неверным результатом, когда домен, который должен указывать на целевой сервис, разрешается в странный адрес. Попробуйте публичный DNS или очистите локальный DNS-кэш, затем проверьте, восстановилась ли работа.
Второй тип — тайм-аут соединения. Если порт блокирует брандмауэр или защитное ПО, запрос может долго ждать, а затем завершиться по тайм-ауту. Проверьте правила разрешения порта и ограничения самой среды, например корпоративной сети или публичного Wi-Fi. Есть простой тест: подключитесь напрямую без прокси. Если и тогда не открывается ни один сайт, проблема в базовой сети, а не в прокси. Перезапустите роутер или переключитесь на мобильную точку доступа, чтобы это подтвердить.
Ошибки сертификата стоит рассматривать отдельно. При сообщении о недоверенном сертификате или неудачном handshake многие сначала подозревают расшифровку трафика или подмену сертификата. Это возможно, но есть и менее очевидная причина: неверное локальное время. Многие механизмы аутентификации и сессий зависят от временных меток. Если локальное время отличается от времени сервера более чем на 5 минут, проверка подписи может не пройти и соединение будет отклонено; в HTTPS это проявляется как ошибка проверки сертификата. При ошибке сертификата проверьте и синхронизацию системного времени. Если она нарушена, включите автоматическую синхронизацию, сразу скорректируйте время, перезапустите клиент и повторите тест.
Не путайте аутентификацию и протокол
Если до прокси-сервера соединение устанавливается, но трафик всё равно не работает, проблема чаще всего на прикладном уровне.
Самая частая причина — данные аутентификации. Имя пользователя, пароль и метод аутентификации должны совпадать с данными провайдера; нередко пароль меняют, но не обновляют в конфигурации. При ручной настройке также убедитесь, что введённый порт совпадает с портом, который слушает само прокси-приложение. Цифры могут быть похожи, но неправильный порт полностью блокирует соединение.
Вторая категория — несовпадение протокола. HTTP, HTTPS и SOCKS5 нельзя смешивать: если провайдер выдал SOCKS5, а в настройках указано HTTP, проверка неизбежно завершится ошибкой. Также убедитесь, что прокси разрешает доступ к целевому сайту и порту, поскольку некоторые прокси ограничивают цели или протоколы.
Самый быстрый способ отличить проблему узла от ошибки конфигурации — проверить другой узел. Если новый работает, проблема в исходном узле. Если результат тот же, вернитесь к настройкам и сетевому пути. Не меняйте сразу несколько параметров: изменяйте по одной переменной и записывайте результат, иначе собственные действия могут скрыть настоящую причину.
Подключение ещё не означает, что среда пригодна к работе
Есть ещё одна частая ловушка. Прокси может показывать нормальное соединение, а учётная запись всё равно регулярно активирует механизмы контроля риска. Тогда вопрос может быть не в самом соединении, а в том, похож ли этот выход на обычную пользовательскую среду.
Проверьте те же основные пункты: совпадает ли география выхода с регионом регистрации аккаунта; подходит ли тип IP, поскольку платформы могут по-разному относиться к IP дата-центров и резидентским IP; не был ли этот IP ранее помечен целевым сайтом? Если через один IP раньше проходило много аномальной активности, это может повлиять на последующих пользователей. После успешного теста соединения потратьте ещё несколько минут на проверку «чистоты» выхода.
Если на одном устройстве работает несколько сред, лучше назначать выходы один к одному: каждой среде — свой выход. Тогда проблемы можно локализовать отдельно, а отметка одного выхода затронет только соответствующую среду, а не все сразу. В управлении несколькими средами PurpleMark именно так раздельно настраивает и изолирует выходы.
Эти методы диагностики предназначены только для технического обмена. Используйте соответствующие инструменты и сервисы в рамках применимых законов и требований.
