Не подключается к серверу TeamSpeak — разбор ошибок

Ошибки подключения TeamSpeak выглядят одинаково — красная строка в окне клиента, — но причины у них разные, и чинятся они в разных местах: на компьютере клиента, на сервере или вообще у провайдера. Текст ошибки почти всегда точно указывает, где искать. Найдите свою строку в списке ниже и переходите к нужному разделу.

Навигатор: ошибка → причина → где чинить

Failed to connect to server, No reply from server — закрыт 9987/UDP на сервере или открыт TCP вместо UDP, сервер выключен, неверный адрес или порт. Смотреть: фаервол сервера, статус сервиса.

Failed to resolve hostname — опечатка в адресе, проблема DNS, битая SRV-запись. Смотреть: адрес в закладке, DNS-записи домена.

the time difference between server and client is too large — сбиты часы или часовой пояс, на клиенте или на сервере. Смотреть: время и пояс на обеих сторонах.

server version is too old for command — сервер устаревшей ветки 3.0.x, современный клиент к нему не подключается. Чинит только владелец: обновить сервер.

The default license has expired — истекла встроенная лицензия старой версии сервера. Тоже только владелец: обновить сервер.

Connection timed out, связь обрывается — фаервол или сеть режет UDP по пути, у части провайдеров блокировка по IP. Смотреть: другая сеть для проверки, трассировка.

You are banned permanently, you may retry in X seconds — бан на сервере, ручной или автоматический от флуд-защиты. Смотреть: список банов сервера, автопереподключение.

Подключение есть, звука нет — это не подключение, а настройки звука: устройства воспроизведения и захвата. Полный разбор — в статье не слышно в TeamSpeak.

Общий принцип диагностики — от простого к сложному: сначала проверить адрес и порт, потом — жив ли сервер, потом — проходит ли до него трафик. Ниже каждый случай разобран отдельно, а в конце — два служебных раздела: проверка со стороны сервера и со стороны клиента.

«Failed to connect to server» и «No reply from server»

Самая частая пара ошибок. Смысл у них один: клиент отправил пакеты по указанному адресу и не получил ответа. Официальная документация называет две причины — по этому адресу и порту не работает сервер, либо соединение блокирует фаервол.

Проверяйте по порядку:

Адрес и порт. Если сервер работает на нестандартном порту, его указывают через двоеточие: ts.example.com:9988. Без порта клиент стучится на 9987 — и если сервер слушает другой порт, ответа не будет. Уточните у владельца сервера точный адрес и порт.

Сервер вообще запущен? Если сервер ваш — раздел «Проверка со стороны сервера» ниже. Если чужой — спросите других участников: подключаются ли они. Если не подключается никто, проблема на сервере, и с вашей стороны чинить нечего.

Фаервол сервера — главный подозреваемый. Голос TeamSpeak ходит только по UDP, стандартный порт — 9987. Классическая ошибка настройки: в фаерволе открывают 9987/TCP, правило выглядит правильным, но клиенты не подключаются, потому что UDP-пакеты по-прежнему отбрасываются. Проверьте правило буквально посимвольно:

sudo ufw status verbose

В выводе должна быть строка 9987/udp ALLOW IN — именно udp. Если написано 9987/tcp или 9987 без протокола не помогает — добавьте явное UDP-правило:

sudo ufw allow 9987/udp comment 'TeamSpeak voice'

Полный разбор портов TeamSpeak, включая команды для iptables и Windows Firewall, — в справочнике по портам.

Сервер дома, за роутером. Тогда кроме фаервола самой машины нужен проброс порта 9987/UDP на роутере — входящие пакеты из интернета иначе не дойдут до компьютера в локальной сети. Игроку, который просто подключается к чужому серверу, проброс портов не нужен никогда.

Фаервол на стороне клиента. Редкая причина, но встречается: антивирус или «фаервол-комбайн» на компьютере блокирует исходящий UDP для незнакомых программ. Для проверки временно отключите его и попробуйте подключиться.

«Failed to resolve hostname»

Клиент не смог превратить имя сервера в IP-адрес. До сервера дело даже не дошло — ошибка целиком про DNS.

Опечатка. Первым делом перечитайте адрес в закладке. Лишний пробел в начале или в конце строки — тоже опечатка, и глазами он не виден.

Проверка по IP. Узнайте IP сервера и подключитесь по нему напрямую (с портом, если он нестандартный). Заработало — значит, сеть в порядке, а проблема в DNS-записях домена.

Битая SRV-запись. Начиная с клиента 3.1 TeamSpeak при подключении по имени запрашивает SRV-запись _ts3._udp.имя — и, что важно, отвергает некорректно оформленные записи, которые старые клиенты молча игнорировали. Типичные дефекты: SRV указывает на несуществующее имя, на IP-адрес вместо имени (по RFC 2782 цель SRV — только имя хоста), на неверный порт, или запись осталась от старого сервера и никто её не обновил. Мёртвая SRV-запись даёт ровно эту ошибку при том, что A-запись домена в полном порядке.

Владелец сервера проверяет записи так:

dig +short A ts.example.com
dig +short SRV _ts3._udp.ts.example.com

A-запись должна вернуть IP сервера; SRV — строку вида 0 5 9987 ts.example.com. — либо ничего (SRV не обязательна, без неё клиент подключится по A-записи на порт из адресной строки). Хуже всего — SRV, которая есть, но врёт: её нужно исправить или удалить. Как правильно оформить обе записи — в инструкции по установке, раздел про привязку домена.

Локальный DNS. Если по имени не резолвится вообще ничего (проверьте nslookup ya.ru в терминале), проблема в DNS-настройках вашей системы или роутера, а не в TeamSpeak.

«The time difference between server and client is too large»

Полный текст: Disconnected from server (the time difference between server and client is too large). Это защитный механизм протокола (появился в ветке 3.1): если часы клиента и сервера расходятся на несколько часов, соединение отклоняется.

Неочевидное: ошибку вызывает и неверный часовой пояс при правильных цифрах на циферблате. Системное время хранится в UTC, и «правильные» 15:00 при чужом поясе — это на самом деле сдвиг на несколько часов.

Локализация простая: не подключается ни к одному серверу — сбиты часы у вас; не подключается только к одному — сбиты часы на нём.

На клиенте (Windows): Параметры → Время и язык → проверьте и часовой пояс, и переключатель «Установить время автоматически», затем «Синхронизировать» — Windows сверится с time.windows.com.

На сервере (Ubuntu/Debian): проверьте состояние:

timedatectl

В выводе смотрите три вещи: текущее время, строку Time zone и System clock synchronized: yes. Если пояс неверный:

sudo timedatectl set-timezone Europe/Moscow

Если синхронизация выключена (NTP service: inactive), включите штатный systemd-timesyncd:

sudo timedatectl set-ntp true

Альтернатива для серверов, где нужна более точная синхронизация, — chrony:

sudo apt install chrony
chronyc tracking

chronyc tracking покажет текущий сдвиг относительно эталона; после установки chrony сам держит часы в тонусе. Достаточно любого одного механизма — timesyncd или chrony, оба сразу не нужны.

«Server version is too old for command»

Полный текст: Disconnected from server (server version is too old for command). Современный клиент отказывается подключаться к серверам устаревшей ветки 3.0.x — это осознанное решение TeamSpeak, а не сбой: в 3.1 сменилась криптография протокола, и старые серверы её не поддерживают.

Со стороны клиента это не лечится. Откат клиента на древнюю версию технически возможен, но плох во всех отношениях: старый клиент не получает исправлений безопасности и не подключится к нормальным современным серверам. Единственное правильное решение — владелец сервера обновляет серверный пакет до актуальной ветки 3.13. База данных при обновлении сохраняется; порядок действий тот же, что при переезде, — описан в инструкции по установке.

Обратной проблемы — «клиент слишком старый для сервера» — бояться не нужно: актуальные серверы принимают клиентов ветки 3.1 и новее, а клиент сам предлагает обновиться. Свежая версия всегда есть на официальной странице загрузок.

«The default license has expired»

Полный текст: The default license has expired. Please use the latest server version. Эта ошибка живёт на стороне сервера: встроенная (бесплатная) лицензия каждой версии сервера имеет срок годности, и когда он истекает, сервер перестаёт запускаться или принимать клиентов — при том, что вчера всё работало и никто ничего не менял. Так массово останавливались серверы 3.13.6 осенью 2022 года, когда истекла их встроенная лицензия; в 3.13.7 её продлили до 1 июля 2027 года.

Клиент при этом видит обычное «Failed to connect» — сам текст про лицензию появляется в логах сервера. Владельцу достаточно заглянуть в каталог logs/ (см. следующий раздел) и, увидев строку про license, обновить сервер до последней версии — это единственное решение, ждать или перезапускать бесполезно. Особенно часто на этом ловятся Docker-инсталляции с прибитым тегом старой версии образа.

«Connection timed out» и блокировки по пути

Если адрес верный, сервер жив, порт открыт, а соединение всё равно не устанавливается или устанавливается и рвётся — трафик теряется где-то между клиентом и сервером. Ошибка может выглядеть как Connection timed out, как зависание на «Connecting…» или как регулярные обрывы уже установленной связи.

Диагностика — методом исключения сетей:

1. Подключитесь с телефона через мобильный интернет (раздайте Wi-Fi точку на компьютер или поставьте мобильный клиент TeamSpeak). Заработало — проблема в вашей домашней сети или у домашнего провайдера.
2. Попросите участника из другого города / с другим провайдером проверить подключение. Если у него работает, а у вас нет ни из домашней сети, ни с мобильного — сужайте дальше.
3. Трассировка покажет, где теряются пакеты: tracert IP_сервера в Windows, traceroute в Linux. Обрыв трассы после узлов провайдера — аргумент в разговоре с его поддержкой.

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

«You are banned» — бан и флуд-защита

Тексты: You are banned permanently (постоянный бан) или Connection failed, you are banned (you may retry in X seconds) (временный). Здесь сервер доступен и отвечает — он осознанно отказывает именно вам.

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

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

Что делать клиенту: выключить автопереподключение в свойствах закладки, выждать указанное в ошибке время полностью и подключиться один раз вручную. Что делать владельцу сервера: посмотреть список банов (в клиенте: Tools → Ban List) и удалить случайные записи, а если легитимные пользователи регулярно попадают под раздачу — поднять пороги флуд-защиты в настройках виртуального сервера (группа параметров Antiflood). Вносить обычных пользователей в query_ip_allowlist.txt не нужно — этот файл относится к ServerQuery, а не к голосовым подключениям.

Отдельный подвид: под флуд-бан попадает сам сервер мониторинга, бот или скрипт, часто опрашивающий ServerQuery, — и в логах растёт стена banned for flooding. Это чинится на сервере добавлением IP бота в query_ip_allowlist.txt — здесь файл уместен, потому что речь именно про query-подключения.

Проверка со стороны сервера

Раздел для владельца: как за две минуты убедиться, что сервер жив и слушает, прежде чем копать глубже.

Сервис запущен?

systemctl status ts3server

Ожидаем Active: active (running). Если сервис лежит или перезапускается по кругу — смотрите journalctl -u ts3server -n 50 --no-pager на предмет ошибок запуска.

Сервер слушает порты?

ss -lnup | grep 9987
ss -lntp | grep 30033

Первая команда должна показать процесс ts3server, слушающий 0.0.0.0:9987 (или конкретный внешний IP) по UDP. Если строки нет — сервер запущен, но порт не поднялся: чаще всего порт занят другим процессом или в ts3server.ini указан другой default_voice_port. Если вместо 0.0.0.0 там 127.0.0.1 — сервер привязан только к localhost и снаружи недоступен по определению.

Что в логах? Содержательные логи TeamSpeak пишет не в journald, а в свои файлы:

ls -lt /opt/teamspeak/teamspeak3-server_linux_amd64/logs/ | head
tail -50 "/opt/teamspeak/teamspeak3-server_linux_amd64/logs/$(ls -t /opt/teamspeak/teamspeak3-server_linux_amd64/logs/ | head -1)"

Ищите строки уровня ERROR и WARNING. Характерные находки: license / accounting — проблемы лицензии (см. раздел про лицензию выше), failed to bind — порт занят, flood / ban — сработала защита. Здоровый запуск выглядит как строка listening on 0.0.0.0:9987 без последующих ошибок.

Фаервол не съедает пакеты? sudo ufw status verbose — правило 9987/udp ALLOW IN должно присутствовать, и именно с UDP. Если фаерволов несколько (ufw плюс правила хостера в панели VDS) — проверить нужно оба уровня: панельный фаервол хостера, закрывающий UDP, снаружи неотличим от локального.

Проверка со стороны клиента

Как проверить доступность сервера снаружи, не имея доступа к нему самому.

Сначала важная оговорка: 9987 — это UDP, и привычные инструменты проверки портов тут не работают. telnet умеет только TCP — он покажет «connection refused» на живом UDP-порту и вообще ничего не докажет. Больше того, даже правильная UDP-проверка принципиально ненадёжна: UDP — протокол без установления соединения, и «порт открыт» в выводе утилиты означает лишь «в ответ не прилетело ICMP-отказа». Отсутствие отказа — это и «порт открыт», и «пакет молча съел фаервол». Поэтому надёжных выводов два: явный отказ = порт закрыт; клиент подключился = порт открыт. Всё между ними — «не доказано».

Linux / macOS — netcat:

nc -u -v -z 203.0.113.10 9987

Флаги: -u — UDP, -v — подробный вывод, -z — только проверка без передачи данных. Мгновенный Connection refused — на порту точно никто не слушает. Ответ open или молчание — порт, вероятно, открыт (или пакеты тихо отбрасываются — см. оговорку выше).

Windows — PowerShell. Штатный Test-NetConnection проверяет только TCP, поэтому для голосового порта он бесполезен, но им удобно проверить файловый порт 30033 — тот как раз TCP, и на типовом сервере оба порта открывают вместе:

Test-NetConnection 203.0.113.10 -Port 30033

TcpTestSucceeded : True означает, что машина доступна и фаервол сервера пропускает трафик TeamSpeak — если при этом голос не подключается, подозрение падает именно на UDP-часть (правило открыто как TCP вместо UDP или UDP режется по пути). Для честной проверки UDP в Windows проще всего поставить netcat из состава nmap (утилита ncat) и выполнить ту же команду, что для Linux.

Самая надёжная проверка — сам клиент из другой сети. Подключение с мобильного интернета или через знакомого в другом городе отвечает на главный вопрос — «сервер вообще доступен снаружи?» — лучше любой утилиты.

Подключились, но не слышно собеседника

Частый случай, который путают с проблемой подключения: в дереве каналов всё видно, ники на месте — но тишина. Разводим сразу: это не сетевая проблема. Раз вы видите сервер и каналы, соединение работает, и всё из разделов выше можно не проверять. Причина — в звуковых настройках, и искать её нужно в другом наборе мест:

• Устройство воспроизведения в клиенте: Tools → Options → Playback — там могло остаться «устройство по умолчанию», которое после подключения наушников смотрит не туда. Выберите устройство явно и нажмите Play Test Sound.
• Локальное заглушение: правый клик по нику собеседника — не стоит ли галочка Mute; рядом с вашим собственным ником — не активен ли значок заглушённых динамиков (клавиша-переключатель нажимается случайно).
• Собеседник молчит для всех: у него не сработал Push-to-Talk (не нажата клавиша, сменилась раскладка, клиент без прав на перехват клавиш) или активация по голосу настроена на слишком высокий порог. Если его не слышит никто в канале — проблема на его стороне.
• Микшер операционной системы: в Windows у каждого приложения своя громкость — TeamSpeak мог быть скручен в ноль в микшере громкости при полном общем звуке.

Если не слышно вообще никого и тестовый звук в настройках клиента тоже не играет — проблема в звуковой подсистеме компьютера, а не в TeamSpeak.

Итого, порядок диагностики: прочитать точный текст ошибки → найти строку в навигаторе в начале статьи → проверить сначала свою сторону (адрес, часы, другая сеть), затем серверную (сервис, порт, фаервол, логи). Подавляющее большинство случаев — это закрытый или открытый не тем протоколом 9987/UDP; полная карта портов с командами для всех фаерволов — в справочнике, а правильная установка сервера, при которой этих проблем не возникает, — в инструкции для Ubuntu.