SOCKS5-прокси на сервере: частые ошибки и решения

MAATRIX

SOCKS5-прокси прост по сути, и его ошибки тоже сводятся к нескольким повторяющимся причинам: неверный внешний интерфейс в конфиге Dante, отказ авторизации, закрытый порт или отсутствие UDP. Ниже — частые ошибки SOCKS5-прокси на сервере, разобранные по симптомам, с командами диагностики прямо на VPS, чтобы находить причину точечно, а не переустанавливать сервер с нуля.

С чего начинать

При любой проблеме сначала смотрите статус сервиса и лог, а затем проверяйте, слушает ли прокси нужный порт. Для Dante это выглядит так:

systemctl status danted
tail -n 40 /var/log/danted.log
ss -lntup | grep 1080

Лог Dante обычно прямо называет причину отказа: не тот интерфейс, ошибка авторизации, отклонённое правилами соединение. Если процесс не слушает порт — проблема на сервере, в конфиге или запуске. Если слушает, но снаружи не отвечает — дело в фаерволе или клиентских параметрах. Эта простая развилка экономит массу времени: вы сразу понимаете, где копать, и не тратите силы на проверку не той половины.

Стоит выработать привычку читать лог, а не гадать. У SOCKS5-прокси почти всегда есть внятное сообщение об ошибке, и оно точнее любых догадок: Dante честно пишет, что отклонил соединение по правилу или не нашёл пользователя, а 3proxy — что провалил авторизацию. Разработчики часто пропускают этот шаг и начинают наугад менять конфиг, из-за чего ломают то, что работало. Правильный порядок обратный: сначала воспроизвели ошибку, посмотрели в лог свежую запись, и только потом трогаете конфигурацию — ровно ту директиву, на которую указывает сообщение.

Полезно также разделять проблему на «моя сторона» и «сторона клиента». Проверка с самого сервера через curl --socks5 на localhost показывает, работает ли прокси в принципе, в отрыве от внешней сети. Если локально всё хорошо, а снаружи нет — причина между клиентом и сервером: фаервол, маршрут или неверные параметры подключения. Такое расщепление на два независимых теста превращает расплывчатое «не работает» в конкретный участок, который и надо чинить.

Не тот внешний интерфейс (Dante)

Специфичная, но очень частая ошибка Dante — неверное имя интерфейса в директиве external. В шаблонах обычно стоит eth0, а на современных серверах интерфейс называется ens3, enp1s0 или иначе. Если имя не совпадает, Dante не сможет выпускать трафик наружу: клиент подключается, но соединения никуда не идут. Узнайте реальное имя интерфейса и подставьте его в конфиг:

ip route get 8.8.8.8

Имя указано после dev. Впишите его в external, перезапустите Dante и проверьте снова. Это лечит целый класс проблем «прокси принимает подключение, но интернета через него нет», характерных именно для Dante.

Отказ авторизации

Клиент вводит логин и пароль, а прокси не пускает. Для Dante с методом username авторизация идёт по системному пользователю — значит, такой пользователь должен существовать в системе, и пароль должен совпадать с системным. Частая ошибка: пользователя завели, но с параметром nologin или без пароля, и авторизация проваливается. Для 3proxy проверьте формат строки users (логин:тип:пароль), наличие auth strong и allow. В обоих случаях перепроверьте, что клиент передаёт именно SOCKS5-авторизацию, а не пытается подключиться без неё. После любых правок в настройках доступа перезапустите сервис, иначе изменения не применятся.

Клиент не подключается вовсе

Соединение висит и обрывается по таймауту. Первым делом проверьте, действительно ли прокси слушает внешний адрес, а не только localhost. Если в конфиге в internal указан 127.0.0.1, снаружи прокси недоступен — там должно быть 0.0.0.0 или внешний адрес сервера. Дальше — фаервол: порт должен быть открыт и в ufw, и, что важнее, в security groups облачной панели. Про внешний фаервол облака забывают чаще всего, и именно он даёт вечно висящее соединение при рабочем сервисе. Проверьте доступ снаружи с другой машины:

curl --socks5 user:pass@ВАШ_IP:1080 https://ifconfig.me

Висящее соединение — закрытый порт или неверный internal; ошибка авторизации — уже прогресс, сеть проходит, чините учётные данные.

Разница между «висит» и «отказ» — важная диагностическая подсказка, и её стоит читать буквально. Если клиент долго ждёт и отваливается по таймауту, пакеты до прокси вообще не доходят: почти всегда это внешний фаервол облака или привязка к localhost. Если же прокси быстро отвечает отказом, сеть в порядке и вы уже общаетесь с сервисом — осталась авторизация или правила доступа. Научившись различать эти два симптома, вы экономите половину времени диагностики: они указывают на совершенно разные слои и требуют разных действий.

Ещё одна ловушка внешнего фаервола — правило открыли, а группу безопасности к серверу не привязали, или привязали к другому. У некоторых провайдеров security group существует отдельно и должна быть явно назначена конкретной машине. Поэтому, открыв порт, проверьте не только текст правила, но и то, что оно действительно относится к вашему серверу. Именно эта мелочь чаще всего стоит за ситуацией «в панели всё разрешено, а SOCKS5-прокси всё равно не пускает снаружи».

Не работает UDP

Часть приложений — игры, голос, некоторые торрент-функции — используют UDP через SOCKS5, и если он не проходит, они работают вполсилы или не работают вовсе. Причины две. Первая — UDP-порт не открыт в фаерволе: TCP открыли, а про UDP забыли; добавьте правило для UDP и в ufw, и во внешней панели облака. Вторая — прокси или его конфигурация не поддерживают UDP-ассоциацию должным образом; убедитесь, что используете реализацию с поддержкой UDP и что правила в конфиге не режут его. Проверьте, что порт слушается по UDP в выводе ss -lntup. Без этого приложения, которым нужен UDP, будут молча деградировать, а пользователь долго не поймёт причину.

Коварство UDP-проблем именно в их незаметности. TCP-часть работает — сайты открываются, авторизация проходит, и на первый взгляд SOCKS5-прокси в порядке. А вот голос заикается, игра теряет пакеты, DNS-запросы через прокси не идут — и связать это с забытым UDP-правилом получается не сразу. Поэтому, если прокси нужен под интерактивные задачи, проверяйте UDP отдельно и сразу, а не полагайтесь на то, что «раз TCP ходит, значит всё настроено». Разные протоколы открываются разными правилами, и одно не гарантирует другого.

IP в бане или капча

Прокси работает, но сервисы отдают капчу, блокировки или не пускают. Это не поломка прокси — это репутация IP. Так бывает, если адрес засвечен, использовался для массовых запросов или лежал в чёрных списках ещё до вас. Особенно быстро репутация портится, если прокси какое-то время стоял открытым без авторизации — его тут же находят боты и гоняют через него мусорный трафик. Проверьте адрес в публичных блэклистах и немедленно закройте прокси авторизацией, если он был открыт. Но испорченную репутацию это уже не вернёт — надёжное решение только одно: чистый, не засвеченный IP. Под работу с чувствительными сервисами и парсинг берите VPS с гарантированно чистым адресом — у MAATRIX его можно арендовать в США, Европе или России с оплатой из России картой, СБП или криптой.

Частые вопросы