Мобільний проксі не працює: діагностика помилок

Мобільний проксі не працює: повна діагностика помилок

Мобільний проксі може перестати працювати з десятків причин: неправильний порт, помилка авторизації, невірно вибраний протокол, DNS, firewall, проблема мобільного оператора, недоступний proxy node або навіть конкретний застосунок, який просто ігнорує системні proxy settings. Тому повідомлення «proxy не працює» саме по собі майже нічого не говорить про реальну причину. Правильна діагностика має йти послідовно: credentials → host/port → protocol → DNS → TCP connection → proxy authentication → destination → GEO/ASN → speed → rotation У цьому гайді розберемо основні проблеми мобільних проксі та покажемо, як визначити, на якому саме етапі виникає помилка.

Спочатку визначте: проблема в proxy чи в сайті

Перед зміною налаштувань перевірте просту річ: чи не працює сам proxy або лише конкретний сайт чи застосунок. Спробуйте:

відкрити кілька різних сайтів;
перевірити зовнішній IP;
відкрити простий IP-check service;
протестувати той самий proxy в іншому browser або client;
перевірити endpoint через curl.

Якщо через proxy не відкривається нічого — проблема, швидше за все, знаходиться на рівні підключення. Якщо більшість сайтів працюють, але один ресурс повертає 403, CAPTCHA або іншу помилку — сам proxy connection може бути справним, а проблема знаходитися на стороні target service.

Перевірте основні дані proxy

Перед складною діагностикою перевірте п’ять базових параметрів:

Host;
Port;
Protocol — HTTP, HTTPS або SOCKS5;
Username;
Password.

Типова конфігурація виглядає так: host:port:username:password Навіть одна зайва цифра в port або пробіл у password може повністю зламати підключення.

Помилка 407 Proxy Authentication Required

407 Proxy Authentication Required означає, що proxy server очікує правильну авторизацію. Найчастіші причини:

не вказаний username;
не вказаний password;
неправильний login/password;
credentials вставлені із зайвим пробілом;
client не підтримує потрібний authentication method;
використовується IP whitelist, але поточний IP не дозволений.

Важливо не плутати: 401 Unauthorized — авторизація потрібна самому website/API. 407 Proxy Authentication Required — авторизація потрібна саме proxy.

Що робити при 407

Скопіюйте username і password заново.
Перевірте відсутність пробілів.
Переконайтеся, що використовуєте credentials саме цього proxy endpoint.
Перевірте, чи не використовується IP whitelist.
Протестуйте proxy іншим client.

Connection Refused

Помилка connection refused зазвичай означає, що client зміг дійти до потрібного host, але TCP-з’єднання на вказаний port не було прийнято. Можливі причини:

неправильний port;
proxy service не запущений;
endpoint тимчасово недоступний;
firewall блокує port;
provider змінив endpoint;
вибраний port не відповідає потрібному protocol.

Наприклад, якщо SOCKS5 працює на одному port, а HTTP на іншому, спроба використати HTTP-client із SOCKS5 port може завершитися помилкою connection або handshake.

Proxy Timeout

Timeout означає, що операція не завершилася за відведений час. Причина може бути не лише в proxy. Timeout може виникнути на етапі:

DNS lookup;
з’єднання з proxy server;
TCP handshake;
TLS handshake;
підключення proxy до target server;
отримання response;
перепідключення мобільного modem.

Як відрізнити повільний proxy від недоступного

Перевірте:

ping;
connect time;
час відкриття простого IP-check URL;
download speed;
upload speed;
кілька різних destination sites.

Якщо прості сайти відкриваються швидко, а один ресурс зависає — проблема може бути саме між proxy network і конкретним destination.

Could Not Resolve Proxy

Це означає, що client не зміг визначити IP самого proxy hostname. Наприклад: proxy.example.com → DNS → ? Причини:

помилка у hostname;
DNS problem;
hostname більше не існує;
локальний DNS-server недоступний;
VPN або firewall втручається у resolution.

Не плутайте це з: Could not resolve host У такому випадку proxy може працювати, але не вдається знайти IP цільового domain.

HTTP Proxy працює, а SOCKS5 — ні

Одна з найпоширеніших причин — client неправильно налаштований або взагалі не підтримує SOCKS5. Перевірте:

чи вибраний саме SOCKS5;
чи правильний port;
чи підтримує client username/password authentication;
чи виконується DNS локально або через proxy;
чи підтримує конкретний software SOCKS5 взагалі.

На Android стандартні Wi-Fi proxy settings зазвичай призначені для HTTP proxy. Для SOCKS5 часто потрібен окремий proxy app. Докладніше: «Як налаштувати мобільний проксі на Android».

SOCKS5 працює, але сайт не відкривається

Перевірте DNS behavior. Деякі clients виконують DNS lookup локально, а деякі передають hostname proxy server. Наприклад, у curl: socks5:// і: socks5h:// мають різну логіку hostname resolution. Якщо IP-підключення працює, але domains не відкриваються, проблема може бути саме в DNS.

403 або 429 — це не завжди проблема proxy

Якщо proxy успішно підключився, а target website повертає:

403 Forbidden;
429 Too Many Requests;
CAPTCHA;
access denied;

це означає, що connection уже дійшов до зовнішнього сервісу. Причина може бути в:

правилах target website;
rate limits;
authorization;
cookies;
session state;
політиках самого сервісу.

Зміна proxy не гарантує вирішення таких обмежень.

Proxy підключився, але GEO неправильне

Наприклад, ви очікували Україну, але IP-check показує іншу країну або неправильне місто. Спочатку перевірте:

external IP;
ASN;
carrier;
country;
результат у кількох GEO databases.

Не варто робити висновок за одним GEO service. Різні IP databases можуть оновлюватися у різний час і показувати різні міста або регіони для тієї самої адреси. Для mobile proxy особливо важливо перевірити ASN та оператора. Наприклад: IP → ASN → Kyivstar / Vodafone / lifecell → Ukraine це набагато інформативніше, ніж лише назва міста в одному GEO checker.

Proxy дуже повільний

Не оцінюйте mobile proxy лише за download speed. Перевірте окремо:

latency;
download;
upload;
packet loss;
час першого connection;
стабільність протягом 20–60 хвилин.

Для SMM та відео upload може бути важливішим за download. Для SEO monitoring важливіші latency і стабільність великої кількості коротких requests. Для browser work важлива загальна responsiveness connection.

Rotation не працює

Проблема з rotation може проявлятися по-різному:

rotation URL не відкривається;
API повертає error;
modem не reconnect;
connection не відновлюється;
IP після rotation залишається тим самим.

Перевірте rotation правильно

Зафіксуйте IP before.
Завершіть активні requests.
Запустіть rotation.
Дочекайтеся відновлення network.
Створіть нове connection.
Перевірте IP after.

Важливо: активне TCP connection може продовжувати використовувати стару session або бути розірване. Після rotation краще створити нове connection. Докладніше про mobile network, CGNAT та ротацію: «Мобільні проксі: 4G/LTE, CGNAT і ротація IP».

Чому IP не змінився після Rotation

Rotation не завжди означає гарантовано унікальний IP. Мобільний оператор призначає адресу зі свого pool. Після reconnect він може:

видати новий IP;
видати інший IP із того самого subnet;
повторно видати попередній IP.

Особливо це можливо, якщо pool невеликий або reconnect виконується дуже часто.

Proxy працює у браузері, але не працює у програмі

Це дуже важлива ознака. Якщо browser працює через proxy, а конкретна програма — ні, проблема, швидше за все, знаходиться у client software. Можливі причини:

app ігнорує system proxy;
app підтримує лише HTTP;
app підтримує лише SOCKS5;
app не підтримує proxy authentication;
частина traffic іде напряму;
використовується UDP, який client не проксіює;
неправильна proxy configuration усередині самого app.

Proxy працює в одному браузері, але не працює в іншому

Перевірте:

browser proxy settings;
extensions;
VPN;
Secure DNS / DoH;
system proxy;
proxy authentication support.

Також переконайтеся, що одночасно не працюють кілька network tools, які намагаються керувати routing.

SSL або TLS Error

Якщо connection до proxy встановлюється, але HTTPS-сайти повертають SSL/TLS error, проблема може бути на іншому рівні. Можливі причини:

проблема TLS handshake;
невірний system time;
certificate validation;
VPN або security software перехоплює HTTPS;
проблема destination server;
неправильний тип proxy.

Не вимикайте certificate verification як постійне «рішення». Спочатку знайдіть реальну причину.

DNS та WebRTC

Proxy може змінювати external IP, але browser при цьому може використовувати інші network mechanisms. Для browser-based work перевіряйте:

external IP;
DNS;
WebRTC;
IPv6;
browser Secure DNS settings.

Proxy — це лише network layer, а не повна заміна browser environment.

Як перевірити HTTP Proxy через curl

Один із найкращих способів відокремити проблему browser від proxy — використати curl. Приклад:

curl -v 
  -x http://proxy-host:port 
  --proxy-user username:password 
  https://api.ipify.org

Якщо команда працює, а browser — ні, перевіряйте browser configuration.

Як перевірити SOCKS5 через curl

curl -v 
  --proxy socks5h://proxy-host:port 
  --proxy-user username:password 
  https://api.ipify.org

socks5h означає, що hostname destination передається SOCKS5 proxy для resolution.

Корисні curl errors

Error	Що перевіряти
5 — Could not resolve proxy	Proxy hostname / DNS
6 — Could not resolve host	Destination DNS
7 — Could not connect	Host, port, firewall, availability
28 — Operation timed out	Network, routing, latency, destination
35 — SSL connect error	TLS / certificates
56 — Receive error	Connection dropped while receiving data
97 — Proxy error	Proxy handshake / protocol

Правильний алгоритм діагностики

Перевірте host.
Перевірте port.
Перевірте protocol.
Перевірте username/password.
Перевірте IP whitelist.
Протестуйте proxy через curl.
Перевірте external IP.
Перевірте ASN та carrier.
Перевірте GEO через кілька services.
Перевірте DNS.
Перевірте download та upload.
Перевірте довгу session.
Перевірте rotation.
Після rotation створіть нове connection.
Лише після цього переходьте до конкретного app.

Що передати Support

Повідомлення: «Проксі не працює» майже не допомагає технічній підтримці. Краще передати:

proxy protocol;
host;
port;
час виникнення проблеми;
текст error;
client / browser / app;
ваш ISP;
чи працює curl test;
IP before/after rotation;
ASN/GEO result;
screenshot або log.

Не передавайте password у відкриті публічні чати або screenshots.

Діагностика мобільних проксі MSOCKS

Для MSOCKS доступні українські mobile proxies через Kyivstar, Vodafone та lifecell/Life з HTTP(S), SOCKS5/UDP, private channel, unlimited traffic та керованою ротацією IP. Перед початком роботи практичніше протестувати:

HTTP(S);
SOCKS5;
IP та ASN;
GEO;
download;
upload;
довгу session;
rotation;
реальний browser або software.

Для Android окремо перевіряйте, чи використовує application системний proxy або потребує власної proxy configuration.

FAQ

Чому proxy повертає 407?

Proxy server вимагає авторизацію або отримав неправильні credentials.

Що означає connection refused?

Client не зміг встановити потрібне TCP connection до endpoint. Перевірте host, port, firewall та availability proxy service.

Чому proxy timeout?

Причиною може бути DNS, TCP/TLS connection, routing, carrier network, destination або занадто повільний response.

Чому SOCKS5 не працює, а HTTP працює?

Перевірте port, client support, authentication і DNS behavior. Не кожний application підтримує SOCKS5.

Чому GEO неправильне?

Різні GEO databases можуть показувати різні результати. Перевіряйте IP, ASN, carrier та кілька GEO services.

Чому Rotation не змінила IP?

Carrier може повторно видати адресу з того самого pool. Також потрібно переконатися, що rotation завершилася і створено нове connection.

Чому proxy працює в browser, але не в app?

Application може ігнорувати system proxy або підтримувати інший protocol.

Чому proxy повільний?

Перевірте latency, routing, download, upload, carrier load і destination. Одна цифра download speed не описує якість connection повністю.

Висновок

Якщо мобільний проксі не працює, не потрібно одразу міняти IP, protocol або provider. Спочатку визначте рівень проблеми: DNS → TCP → Proxy → Authentication → Destination → GEO → Speed → Rotation → Application Найефективніший підхід — змінювати лише один параметр за раз і після кожного кроку повторювати test. Так замість хаотичної заміни налаштувань можна точно визначити, чи проблема знаходиться в credentials, proxy endpoint, mobile network, DNS, конкретному software або самому target service.