CCcam.cfg 2026: настройка конфига и синтаксис
Если ты уже потратил час на попытки поднять рабочее соединение и демон всё равно молчит — скорее всего проблема в конфиге. Файл CCcam.cfg простой, но малейшая опечатка или лишний символ убивают всё подключение. Здесь разберём актуальный синтаксис и пути для cccam cfg 2026, включая нюансы, которые обычно нигде не документированы.
Что такое CCcam.cfg и где он лежит
Назначение файла конфигурации
CCcam.cfg — единственный файл, который демон CCcam читает при старте. Всё в нём: куда подключаться, кого впускать, на каком порту слушать, какие ключи использовать. Нет конфига — нет работы. Неправильный конфиг — то же самое.
Демон читает файл один раз при запуске и кэширует настройки. Это значит: поправил файл, забыл перезапустить — работает по старому конфигу. Всегда делай рестарт после правки.
Пути к файлу на разных прошивках
Здесь начинается первый подводный камень. В зависимости от прошивки ресивера файл лежит в разных местах:
/var/etc/CCcam.cfg— стандартный путь для Enigma2 (OpenPLi, OpenATV, OpenVIX и большинство современных сборок)/etc/CCcam.cfg— старые прошивки на базе DM500/DM600, некоторые сборки под Linux-сервер/usr/keys/CCcam.cfg— встречается на части Gemini и аналогичных прошивок/etc/cccam/CCcam.cfg— если CCcam установлен как пакет в некоторых дистрибутивах
Проблема в том, что на некоторых ресиверах несколько конфигов могут существовать одновременно в разных директориях. Демон читает только один — тот, который прописан в скрипте запуска. Проверь через cat /etc/init.d/cccam или ps aux | grep CCcam с каким параметром запущен процесс.
Права доступа и кодировка файла
Файл должен иметь права 644: chmod 644 /var/etc/CCcam.cfg. Если права будут 600 или 777 — на некоторых прошивках демон откажется его читать.
Кодировка — UTF-8 без BOM. Вот что убивает конфиги чаще всего: редактор на Windows сохраняет файл с BOM-маркером (три байта в начале: EF BB BF). Демон CCcam не понимает BOM и либо не стартует, либо стартует но не читает первую строку. Никакой видимой ошибки при этом нет. Если правишь в Notepad — не используй его. Notepad++, VSCode с явным указанием UTF-8 without BOM, или nano на самом ресивере — всё это работает нормально.
Проверить наличие BOM можно командой: hexdump -C /var/etc/CCcam.cfg | head -1. Если первые байты ef bb bf — BOM есть, нужно пересохранить.
Синтаксис основных строк CCcam.cfg
Строка C: — подключение к серверу
Формат строки подключения к удалённому серверу:
C: hostname port username password [no/yes] [no/yes]
Разбор по полям:
- hostname — DNS-имя или IP сервера, например
myserver.example.com - port — TCP-порт, чаще всего 12000, но может быть любым
- username — логин, выданный провайдером
- password — пароль к этому логину
- первый булев параметр — управляет wantemus (запрос share-листа).
noпо умолчанию,yesвключает - второй булев параметр — keepalive/reconnect behavior. Разные версии CCcam трактуют это поле по-разному
Минимальная рабочая строка выглядит так:
C: myserver.example.com 12000 mylogin mypassword
Важный момент: CCcam 2.x и CCcam 2.3.x читают необязательные поля немного иначе. В версии 2.3.x оба булевых поля влияют на поведение reconnect-таймера, в более старых версиях второе поле вообще игнорируется. Если у тебя старая прошивка — не добавляй лишние поля, это может вызвать проблемы парсинга.
Строка F: — приём входящих клиентов
Строка F: описывает friend — пользователя, которому ты разрешаешь подключаться к своему серверу:
F: username password [uphops] [downhops] [no/yes] [shares]
- username и password — учётные данные клиента
- uphops — сколько хопов вверх клиент может видеть (0 = только локальные карты)
- downhops — сколько хопов клиент может ре-шарить дальше (0 = не может шарить)
Пример: F: clientuser clientpass 1 0 — клиент видит карты с одним хопом, но не может раздавать их дальше.
Строка N: — newcamd-подключение
Строка N: используется для подключения по протоколу Newcamd. Формат:
N: hostname port username password DES_key
DES-ключ — 28 байт в hex-формате, например: 01 02 03 04 05 06 07 08 09 10 11 12 13 14. Если ключ не совпадает с серверным — подключение упадёт с ошибкой авторизации. Newcamd используется реже, чем CCcam-протокол, но на некоторых серверах он единственный доступный вариант.
Параметры hop, recv/send dare, share limits
Hop-count — это расстояние от физической карты до клиента. Hop 0 = карта вставлена локально. Hop 1 = карта на сервере, к которому ты подключён напрямую. Hop 2 = карта ещё на одном сервере дальше. Чем выше hop — тем больше задержка ECM.
В конфиге можно ограничить максимальный hop для входящих клиентов через директиву SHARE LIMIT:. Это защищает от ситуации, когда твой сервер становится ретранслятором в длинной цепочке.
Настройка клиента и сервера: пошагово
Конфиг клиента: добавление строки C:
Минимальный рабочий конфиг клиента выглядит так:
# CCcam.cfg — client config
C: myserver.example.com 12000 mylogin mypassword
CLIENTNAME: MyReceiver
LOGLEVEL: 3
LOGFILE: /tmp/cccam.log
Можно добавить несколько строк C: — CCcam будет пробовать подключиться к каждому серверу и использовать первый ответивший. Это хорошо для отказоустойчивости.
Конфиг сервера: открытие порта и строки F:
Если ты поднимаешь сервер, который будет принимать клиентов:
# CCcam.cfg — server config
SERVER LISTEN PORT: 12000
WEBINFO LISTEN PORT: 16001
ALLOW TELNET: yes
F: client1 pass1 1 0
F: client2 pass2 1 0
LOGLEVEL: 3
LOGFILE: /tmp/cccam.log
Параметры сервера: SERVER LISTEN PORT, ALLOW TELNET
SERVER LISTEN PORT — порт, на котором демон ждёт входящих CCcam-клиентов. По умолчанию 12000, но можно поставить любой незанятый. Этот порт нужно открыть в фаерволе и пробросить через роутер если ты за NAT.
WEBINFO LISTEN PORT — порт веб-интерфейса, по умолчанию 16001. Через него видно статус карт, ECM time, список подключённых клиентов.
ALLOW TELNET: yes — включает telnet-интерфейс для диагностики. В продакшне лучше держать выключенным, но при настройке удобно.
Проверка соединения через лог и веб-интерфейс
Открой браузер: http://192.168.1.100:16001 (IP твоего ресивера). Если CCcam запущен и конфиг правильный — увидишь страницу с количеством карт и статусом соединений.
Что смотреть:
- Cards — количество карт, которые видит демон. Ноль карт = сервер недоступен или нет авторизации
- ECM time — время ответа на запрос дешифрования. Нормально: до 300мс. Плохо: 800мс и выше, будут фризы
- Status — CONNECTED/DISCONNECTED для каждой строки C:
Параллельно читай лог: tail -f /tmp/cccam.log. Там видно попытки подключения, ошибки авторизации и ECM-запросы.
Частые ошибки CCcam.cfg и их решение
Сервер не отвечает: проверка порта и фаервола
Первый шаг диагностики — проверить, доходит ли соединение вообще:
telnet myserver.example.com 12000
Если telnet висит и ничего не происходит — порт закрыт. Причины: фаервол на сервере, роутер не пробрасывает порт, сервер вообще не поднят. Проверь iptables на сервере:
iptables -L -n | grep 12000
Если правила нет — добавь: iptables -A INPUT -p tcp --dport 12000 -j ACCEPT. Если роутер за NAT — добавь проброс порта в настройках роутера.
Двойной NAT — отдельная головная боль. Если и клиент и сервер за разными NAT без проброса портов, входящие F:-клиенты физически не смогут подключиться. Тут нужен либо VPN, либо сервер с белым IP.
Карты есть, но каналы не открываются (ECM timeout)
Это самая частая ситуация после того как правильно составлен cccam cfg 2026: веб-интерфейс показывает карты, канал выбирается, но через 3-5 секунд появляется "no signal" или чёрный экран.
Причины по убыванию вероятности:
- Высокий hop — карта далеко, ECM time 600-1000мс, тюнер не успевает
- CAID совпадает, но Provider ID нет — карта видна, но не дешифрует этот конкретный канал
- Перегруженный сервер — ECM time нормальный в тихие часы, но вечером в прайм-тайм растёт до 1500мс
- Карта на сервере деактивирована — CAID в листе есть, но реально уже не работает
Решение для проверки Provider ID: зайди в веб-интерфейс, найди список карт, посмотри какие Provider ID есть у нужного CAID. Сравни с тем что нужно конкретному каналу.
Неверный синтаксис строки — демон не стартует
Демон CCcam при ошибке парсинга конфига просто не запускается и не пишет внятной ошибки. Частые причины:
- BOM в файле (описано выше)
- Пробел перед C: в начале строки — парсер не распознаёт директиву
- Табуляция вместо пробела между полями
- Символы возврата каретки Windows (CRLF) вместо Unix-переносов (LF)
- Незакрытые кавычки или нелатинские символы в пароле
Исправить CRLF: sed -i 's/\r//' /var/etc/CCcam.cfg. После этого перезапустить демон и смотреть лог.
Конфликт CCcam с OScam на одном ресивере
Это вполне рабочая связка, если правильно разнести роли. OScam умеет работать как картоприёмник (читает физическую карту) и одновременно как CCcam-сервер — это называется режим cccam-reader в OScam. CCcam при этом подключается к OScam как обычный клиент через строку C:.
Обратная схема тоже работает: CCcam запущен как клиент к внешнему серверу, OScam подключается к CCcam через cccam-протокол и раздаёт карты своим клиентам.
Главное — порты. CCcam и OScam не должны слушать один и тот же порт. Стандартно: CCcam на 12000, OScam на 11000 или 11200. Если оба пытаются занять 12000 — один из них упадёт, и ты будешь час искать почему.
Проверить кто занял порт: netstat -tlnp | grep 12000.
Как выбрать качественное подключение в 2026
Критерии стабильности: uptime, ECM time, локальные карты
При оценке любого подключения смотри на три параметра. ECM time должен быть стабильно ниже 300мс — это граница, выше которой начинаются видимые задержки при переключении каналов. Не 300мс в тесте ночью, а 300мс в пятницу вечером когда все смотрят матч.
Uptime — минимум 99.5% за месяц. Любые плановые или внеплановые окна обслуживания должны быть короткими и редкими.
Самый надёжный вариант — локальная официальная карта в собственном картоприёмнике. Никаких хопов, никакой зависимости от чужого сервера, ECM time 50-80мс. Если есть возможность — это единственный правильный выбор.
Признаки перепроданного (oversold) сервера
Oversold — когда на один сервер с одной картой продано больше подключений, чем карта физически может обслужить. Симптомы:
- ECM time нормальный утром, 800-1200мс вечером
- Периодические фризы на 2-5 секунд без разрыва соединения
- Веб-интерфейс показывает карты, но часть CAID не дешифрует
- Массовые отключения клиентов в прайм-тайм
Такой сервер исправить невозможно — нужно менять. Проверяй это в первые дни после подключения, а не через месяц.
Юридические и технические риски
Card sharing — юридически серая зона в большинстве стран. В ряде европейских государств это прямо квалифицируется как нарушение авторских прав и условий подписки. Провайдеры активно работают с Nagravision, Conax и другими системами условного доступа, периодически проводя массовые деактивации карт.
С технической стороны: любые внешние подключения означают зависимость от третьего лица. Сервер падает, карту деактивируют, провайдер исчезает — и ты остаёшься без сигнала. Это не теория: такое происходит регулярно, особенно после обновлений прошивки на стороне вещателя.
Локальное решение vs внешнее подключение
Если есть официальная подписка на нужные каналы — физическую карту в ресивер и локальный OScam-сервер для других устройств в доме. Никакой внешней зависимости, минимальный ECM time, никаких рисков.
Внешнее подключение имеет смысл только для каналов, которые иначе физически недоступны в твоём регионе — и то при понимании всех рисков.
Где находится файл CCcam.cfg на ресивере с Enigma2?
Стандартный путь — /var/etc/CCcam.cfg. На части прошивок это /etc/CCcam.cfg или /usr/keys/CCcam.cfg. Проверь через ps aux | grep CCcam с каким путём запущен демон — увидишь точно. После любой правки файла обязателен рестарт: /etc/init.d/cccam restart.
Что означают поля в строке C: в CCcam.cfg?
Формат: C: host port username password. После пароля два необязательных булевых поля (no/yes): первое управляет запросом share-листа (wantemus), второе влияет на поведение keepalive. Минимальная рабочая строка — только четыре обязательных поля. В CCcam 2.3.x необязательные поля трактуются иначе, чем в версии 2.x.
Почему CCcam подключается, но каналы не открываются?
Скорее всего ECM timeout. Причины: высокий hop-count (карта далеко), перегруженный сервер (ECM time растёт в прайм-тайм), или карта видна но Provider ID не совпадает с нужным каналом. Открой веб-интерфейс на порту 16001 и проверь ECM time в реальном времени — это даёт ответ быстрее любой другой диагностики.
Какой порт открыть для входящих клиентов CCcam?
Порт задаётся директивой SERVER LISTEN PORT: 12000 в CCcam.cfg. 12000 — стандартный, но можно использовать любой. Этот порт нужно разрешить в iptables (iptables -A INPUT -p tcp --dport 12000 -j ACCEPT) и пробросить через роутер если ресивер за NAT.
Можно ли использовать CCcam и OScam одновременно?
Да, это рабочая связка. Вариант 1: OScam читает физическую карту и раздаёт через cccam-протокол, CCcam подключается к OScam как клиент. Вариант 2: CCcam подключается к внешнему серверу, OScam берёт карты у CCcam. Главное — разные порты: если оба процесса попытаются занять один порт, один из них упадёт.
Как проверить, что конфиг CCcam.cfg рабочий?
Открой http://[ip-ресивера]:16001 в браузере — веб-интерфейс CCcam покажет количество карт, ECM time и статус каждого соединения. Параллельно смотри лог: tail -f /tmp/cccam.log. Ноль карт при статусе CONNECTED означает авторизацию прошла, но сервер не шарит карты — проблема на стороне сервера, не в твоём конфиге.
Если после всего этого конфиг всё ещё не работает — сравни актуальный синтаксис с документацией твоей версии CCcam. Именно для этого стоит держать под рукой рабочий пример cccam cfg 2026 и сверяться с ним при каждой правке.
Практические советы для стабильного просмотра
Даже самая стабильная линия CCCam или OSCam требует пары простых подготовительных шагов. Обновляйте прошивку ресивера, раз в неделю очищайте ECM‑кеш и держите 15–20% свободного места на USB‑накопителе или во встроенной памяти, чтобы кардридер записывал ключи без задержек.
При настройке антенны оставляйте запас по MER/BER: смещение на два градуса или ослабленный F‑коннектор чаще становится причиной “фризов”, чем сам кардшаринг. Держите под рукой короткий патч‑корд для проверки другого роутера и сохраните два профиля в OSCam — под TCP и под UDP — чтобы мгновенно переключиться, если провайдер начнёт фильтровать протокол.
Utgard.tv следит за каждым хабом 24/7, однако вы можете ускорить диагностику, если будете вести небольшой журнал действий. Записывайте время переключения канала, активный CAID и то, использовали ли вы Wi‑Fi или Ethernet. Такой мини‑отчёт позволит инженерам воспроизвести вашу конфигурацию в лаборатории и предложить решение не за часы, а за минуты.
- Держите активными две линии: если первый сервер уходит на обслуживание, второй тут же подхватывает поток без повторного ввода логина.
- Раз в месяц делайте замер скорости и задержек. Стабильных 1–2 Мбит/с при пинге до 80 мс достаточно для SD/HD, но если джиттер превышает 20 мс — переведите роутер на провод.
- Сохраните в закладки страницу статуса Utgard.tv и Telegram‑бота @utgard_tv_bot — там появляются уведомления о работах раньше, чем успеют среагировать SEMrush или внешние мониторы.