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

MAATRIX

Icecast — потоковый аудиосервер, который почти не менялся с начала 2000-х: тот же протокол, та же логика mountpoint'ов, те же грабли. Это одновременно и плюс (стабильность, минимум сюрпризов), и минус — большинство мануалов в интернете написаны десять лет назад и не учитывают современный systemd, ufw по умолчанию и обязательный HTTPS. Ниже — разбор ошибок, с которыми реально сталкиваешься при поднятии интернет-радио на своём сервере, и рабочие решения без воды.

Установка Icecast и структура icecast.xml

На Ubuntu/Debian ставится из репозитория:

apt update
apt install -y icecast2

Инсталлятор Debian-пакета сам спросит hostname, пароли и порт — но эти диалоги удобнее пропустить и сразу править конфиг руками:

nano /etc/icecast2/icecast.xml

Ключевые блоки конфига, на которые стоит обратить внимание сразу:

<icecast>
    <location>Earth</location>
    <admin>admin@example.com</admin>

    <limits>
        <clients>200</clients>
        <sources>5</sources>
        <queue-size>524288</queue-size>
        <client-timeout>30</client-timeout>
        <header-timeout>15</header-timeout>
        <source-timeout>10</source-timeout>
        <burst-size>65535</burst-size>
    </limits>

    <authentication>
        <source-password>change_me_source</source-password>
        <relay-password>change_me_relay</relay-password>
        <admin-user>admin</admin-user>
        <admin-password>change_me_admin</admin-password>
    </authentication>

    <hostname>stream.example.com</hostname>

    <listen-socket>
        <port>8000</port>
        <bind-address>0.0.0.0</bind-address>
    </listen-socket>

    <fileserve>1</fileserve>

    <paths>
        <basedir>/usr/share/icecast2</basedir>
        <logdir>/var/log/icecast2</logdir>
        <webroot>/usr/share/icecast2/web</webroot>
        <adminroot>/usr/share/icecast2/admin</adminroot>
        <alias source="/" destination="/status.xml"/>
    </paths>

    <logging>
        <accesslog>access.log</accesslog>
        <errorlog>error.log</errorlog>
        <loglevel>3</loglevel>
        <logsize>10000</logsize>
    </logging>

    <security>
        <chroot>0</chroot>
    </security>
</icecast>

Главные пароли — source-password (им подключается кодер/источник) и admin-password (веб-панель /admin/). Оставить их дефолтными — первая типовая ошибка: боты сканируют порт 8000 и подбирают source-пароль, чтобы вклинить свой поток в чужой mountpoint. Меняйте оба пароля на строки от 16 символов сразу после установки.

Пакет ставит два конфликтующих управляющих файла — /etc/default/icecast2 с флагом ENABLE=false по умолчанию. Если сервис не стартует после apt install, проверьте именно его:

cat /etc/default/icecast2
# должно быть: ENABLE=true
systemctl restart icecast2

Ошибка "Address already in use" и конфликт портов

Icecast по умолчанию слушает 8000/tcp. Типичная картина после systemctl restart icecast2:

[2026-08-29  10:14:02] ERRO listensocket/listensocket_create_and_bind Could not create listener on port 8000: Address already in use

Проверяем, кто занял порт:

ss -tlnp | grep 8000

Частые виновники — второй запущенный экземпляр icecast (если стартовали вручную icecast2 -c /etc/icecast2/icecast.xml поверх уже работающего systemd-юнита), либо другой сервис, который тоже решил слушать 8000 (нередко — самописный прокси или тестовый Node.js-сервер). Решения:

• убить лишний процесс: kill $(lsof -t -i:8000);
• либо перенести Icecast на другой порт, если 8000 занят осознанно другим сервисом — правится в <listen-socket><port>;
• если нужно несколько потоков на разных портах (например, публичный 8000 и тестовый 8010), просто добавьте второй блок <listen-socket> в тот же icecast.xml — Icecast умеет слушать несколько портов одновременно без второго инстанса.

Ещё один вариант той же ошибки — порт 8000 уже держит зомби-процесс от предыдущего краша Icecast, который не освободил сокет из-за SO_REUSEADDR. Помогает systemctl stop icecast2 && sleep 2 && systemctl start icecast2 — просто restart без паузы иногда не успевает.

Источник (source) не подключается: авторизация и mountpoint

Самая частая жалоба: кодер (Liquidsoap, BUTT, mixxx, ffmpeg) пишет "403 Forbidden" или "Authentication failed" при попытке залить поток. Разбор по шагам.

Проверка вручную через curl — самый быстрый способ понять, где именно рвётся:

curl -v -i -X SOURCE -H "Content-Type: audio/mpeg" \
  --user source:change_me_source \
  http://your-server-ip:8000/stream.mp3 --data-binary @test.mp3

Если в ответ 401 — пароль неверный или логин не source (для protocol v1 логин всегда буквально source, меняется только пароль). Если 403 — либо mountpoint уже занят другим источником, либо в конфиге не разрешено create mountpoint "на лету".

Пример конфига источника на ffmpeg (частый вариант для трансляции с готового аудиопотока или файла):

ffmpeg -re -i input.mp3 -c:a libmp3lame -b:a 128k -content_type audio/mpeg \
  -f mp3 icecast://source:change_me_source@your-server-ip:8000/stream.mp3

Liquidsoap — стандарт для радио 24/7 с плейлистом и джинглами:

radio = playlist("/home/radio/playlist.m3u")
radio = fallback(track_sensitive=false, [radio, blank()])

output.icecast(%mp3(bitrate=128),
  host="localhost", port=8000,
  password="change_me_source",
  mount="stream.mp3",
  radio)

Частые причины 403/refused connection:

• Mountpoint уже занят. Icecast по умолчанию не даёт двум источникам писать в один /stream.mp3 одновременно — второе подключение получит отказ. Проверьте /admin/listclients?mount=/stream.mp3 под admin-логином или просто systemctl status icecast2 на предмет уже активного source.
• <mount> не задан явно, а <authentication> в нём переопределяет пароль. Если в icecast.xml есть блок <mount><mount-name>/stream.mp3</mount-name>...</mount> со своим <password>, глобальный source-password для этого mountpoint не работает — источник должен использовать именно локальный пароль.
• Firewall режет исходящее с сервера кодера, если кодер сам стоит за NAT/VPN — тут дело не в Icecast, а в сети клиента, диагностируется через telnet your-server-ip 8000 с машины кодера.

Слушатели отваливаются: лимиты и firewall

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

1. Firewall на сервере. Если стоит ufw, порт 8000 по умолчанию закрыт:

ufw allow 8000/tcp
ufw status

Подробный разбор типовых граблей самого ufw — в статье про частые ошибки файрвола, многие ситуации совпадают с тем, что ловят на Icecast.

1. Лимит клиентов исчерпан. <limits><clients>200</clients> — это суммарный лимит на все mountpoint'ы сразу, а не на один поток. При росте аудитории увеличивайте вместе с <queue-size> и <burst-size> — burst-size маленький вызывает заикание в начале воспроизведения у новых слушателей, потому что плееру не хватает буфера для старта.

1. Системный лимит открытых файлов. Каждое TCP-соединение слушателя — это файловый дескриптор. Дефолтный ulimit в 1024 упрётся раньше, чем лимит в самом Icecast, если аудитория заметно больше сотни одновременных слушателей:

# /etc/systemd/system/icecast2.service.d/override.conf
[Service]
LimitNOFILE=65535

systemctl daemon-reload
systemctl restart icecast2
ss -s   # проверить текущее число соединений

1. Обрывы у мобильных слушателей — почти всегда не проблема Icecast, а нестабильный аппер на мобильной сети плюс маленький burst-size. Увеличение burst-size до 128–262144 байт сглаживает переподключения, но не устраняет их полностью — это ограничение протокола, а не конфигурации.

Проброс через nginx и HTTPS для потока

Сам Icecast HTTPS не умеет — у него нет встроенного TLS. Слушать поток по http:// в 2026 году — плохая идея: браузеры блокируют autoplay и mixed content на HTTPS-сайтах, если плеер вставлен на защищённую страницу. Решение — reverse proxy через nginx с уже выпущенным сертификатом.

server {
    listen 443 ssl http2;
    server_name stream.example.com;

    ssl_certificate     /etc/letsencrypt/live/stream.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/stream.example.com/privkey.pem;

    location /stream.mp3 {
        proxy_pass http://127.0.0.1:8000/stream.mp3;
        proxy_set_header Host $host;
        proxy_buffering off;
        proxy_set_header Connection "";
        proxy_http_version 1.1;
        chunked_transfer_encoding off;
        add_header Access-Control-Allow-Origin *;
    }

    location /admin/ {
        proxy_pass http://127.0.0.1:8000/admin/;
        proxy_set_header Host $host;
        # ограничьте доступ по IP отдельно, admin-панель наружу лучше не светить
    }
}

Критично важная строка — proxy_buffering off. Без неё nginx буферизует ответ Icecast целиком перед отправкой клиенту, а поток по своей природе бесконечный — слушатель просто не получит вообще ничего, пока буфер не заполнится (то есть никогда). Это самая частая причина "через nginx поток не работает, а напрямую по IP:8000 работает".

Сертификат для домена выпускается стандартно — если ранее не настраивали Let's Encrypt на сервере, шаги подробно описаны в статье про установку SSL-сертификата, включая типовые ошибки валидации.

После проброса не забудьте закрыть 8000 порт наружу (оставить только 127.0.0.1) и открыть только 443:

ufw deny 8000/tcp
ufw allow 443/tcp

Логи, мониторинг и автозапуск через systemd

Icecast пишет два лога — access.log (кто и когда слушал/подключался как источник) и error.log (сбои). Оба лежат в /var/log/icecast2/ по умолчанию:

tail -f /var/log/icecast2/error.log
tail -f /var/log/icecast2/access.log

Если в access.log видите строки со статусом 403 от source-запросов раз в несколько минут — это боты подбирают source-пароль, не мониторинг ошибка, а сигнал сменить пароль на более длинный и, при желании, добавить fail2ban-правило под Icecast (готового jail в стандартной поставке нет, пишется вручную по regexp из access.log).

Автозапуск после перезагрузки сервера включается штатно через systemd:

systemctl enable icecast2
systemctl status icecast2
journalctl -u icecast2 -n 50 --no-pager

Если нужен веб-мониторинг (аптайм, число слушателей, битрейт) поверх системных метрик, а не только встроенная админка Icecast на /admin/stats — подойдёт связка Prometheus + Grafana с node_exporter, разобранная в статье про установку Grafana и Prometheus: текстовый экспортёр можно скармливать данными из XML-статистики Icecast через простой cron-скрипт.

Ротация логов не настраивается автоматически пакетом на всех дистрибутивах — проверьте, что есть файл /etc/logrotate.d/icecast2, иначе access.log при активном радио с десятками слушателей за месяц может вырасти до гигабайтов.

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