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 или внешние мониторы.