У разі збою проксі перевіряйте три рівні: спочатку зміну 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 у керуванні кількома середовищами саме так окремо налаштовує та ізолює виходи.
Ці методи діагностики наведено лише для технічного обміну. Використовуйте відповідні інструменти й сервіси з дотриманням чинного законодавства та правил.
