Прокси для OScam: настройка reader-прокси 2026

Прокси для OScam — тема, где каждый второй форумный пост говорит о разном, и это главная причина путаницы. Одни имеют в виду SOCKS5-туннель для трафика, другие — промежуточный сервер в цепочке кардшаринга. Это принципиально разные вещи, и если не понимать разницу, конфиг будет нерабочим независимо от того, сколько часов в него вложено.

Здесь разбираю оба случая: и настройку proxy-reader в oscam.server, и заворачивание трафика через внешний туннель на уровне ОС. С реальными конфигами, командами и расшифровкой логов.

Что такое прокси в контексте OScam и зачем он нужен

OScam может быть одновременно сервером для клиентов и клиентом для вышестоящего источника. Это и есть прокси-режим: принять запрос ECM снизу, передать вверх, вернуть CW обратно. Никакой физической карты в этой схеме нет.

Прокси для OScam в большинстве случаев — это именно такой relay-сервер, который настраивается через секцию [reader] в oscam.server. Не SOCKS5, не HTTP-прокси — а reader с network-протоколом.

Разница между прокси-reader и обычным cardreader

Обычный cardreader в OScam смотрит на физическое устройство: device = /dev/ttyUSB0 или PCSC. У него есть реальная смарт-карта, он сам декодирует ECM.

Proxy-reader смотрит на хост и порт вышестоящего сервера: device = upstream.example.com,12000. Карты у него нет — он ретранслирует запросы дальше по цепочке. Protocol здесь будет cccam, newcamd или camd35 — зависит от того, что отдаёт вышестоящий сервер.

Сценарии применения: реле, цепочки, скрытие IP, агрегация источников

Реле нужно, когда вышестоящий сервер не принимает подключения с вашего IP напрямую, а промежуточная точка — принимает. Или когда надо собрать несколько источников в один сервер и раздавать клиентам из одной точки.

Агрегация источников — тоже распространённый случай: несколько [reader] с разными серверами, все в одной группе, OScam сам балансирует между ними по скорости ответа.

Чем OScam-прокси отличается от системного SOCKS/HTTP-прокси

Встроенной поддержки SOCKS5 для протоколов newcamd и cccam в OScam нет. Это не баг, это просто не реализовано. Если вам нужно завернуть исходящий card-трафик через SOCKS5, делать это надо на уровне операционной системы — через redsocks, tun2socks или VPN-интерфейс.

Веб-интерфейс OScam (httpport) — другое дело, его можно и нужно прятать за nginx как reverse-proxy. Но это только веб-морда, не card-протоколы.

Настройка proxy-reader в oscam.server

Конфиги OScam лежат в разных местах в зависимости от образа. На Enigma2-боксах обычно /etc/tuxbox/config/oscam/, на Debian/Ubuntu-серверах — /etc/oscam/, на некоторых сборках /var/keys/ или /usr/keys/. Файл, который нас интересует — oscam.server.

Вот минимальная рабочая секция proxy-reader:

[reader]
label         = upstream_cccam
protocol      = cccam
device        = upstream.example.com,12000
user          = myuser
password      = mypassword
group         = 1
cccversion    = 2.3.0
cccmaxhops    = 10
ccckeepalive  = 1
reconnecttimeout = 30
inactivitytimeout = 60

Параметры секции [reader]: protocol, device, user, password

protocol должен совпадать с тем, что ожидает вышестоящий сервер. CCcam-сервер — cccam. Newcamd-сервер — newcamd. Не угадывайте, смотрите в настройки источника.

device — это hostname,port без пробелов. Если вышестоящий сервер за CGNAT или с динамическим IP, нужен DDNS: в поле device прописываете доменное имя вроде myserver.ddns.net,12000, а не IP. Иначе при смене адреса придётся лезть в конфиг вручную.

Ключевые поля: group, cccversion, cccmaxhops, ccckeepalive

group — это связующее звено между reader и account. Reader с group = 1 будет отдавать карты только тем account, у которых тоже прописано group = 1. Без совпадения групп карты не пробрасываются — и это самая частая причина, почему схема не работает.

cccmaxhops определяет, с какой глубины хопов принимать карты. По умолчанию обычно 0 или 1, а это значит, что карты, которые вышестоящий сервер сам получил от третьего сервера, к вам уже не дойдут. При построении цепочек ставьте cccmaxhops = 10 или даже выше.

ccckeepalive = 1 включает keepalive-пинги, чтобы соединение не рвалось при простое. Для прокси-режима это обязательно.

Порты по умолчанию и inactivitytimeout

CCcam слушает на порту 12000 — это де-факто стандарт. Newcamd обычно 15050, но конкретный порт всегда определяет вышестоящий сервер. Проверяйте именно там.

inactivitytimeout — если соединение простаивает дольше заданного времени (в секундах), OScam его разрывает и переподключается. Значение 60 секунд — разумный компромисс. Слишком большое значение приводит к зависанию мёртвых соединений: сокет открыт, данные не идут, OScam этого не замечает.

Параметр reconnecttimeout и audisabled для прокси-режима

reconnecttimeout = 30 означает, что после разрыва OScam подождёт 30 секунд перед повторной попыткой. Слишком маленькое значение — флуд подключениями, вас могут забанить на вышестоящем сервере. Слишком большое — долгий простой при временных сетевых проблемах.

Параметр audisabled = 1 отключает логирование AU (card update) для этого reader. Если reader — чисто прокси без физической карты, AU всё равно не работает, и запись лишних ошибок в лог только мешает диагностике.

Раздача через oscam.user и построение цепочки серверов

OScam-прокси одновременно является клиентом для вышестоящего сервера и сервером для нижестоящих клиентов. Настройка «серверной» части делается в oscam.user.

Секция [account]: создание исходящего пользователя для клиента

[account]
user          = client1
password      = clientpass
group         = 1
cccreshare    = 10
uniq          = 0

Этот account будет выдавать карты клиенту, подключающемуся к нашему прокси. cccreshare определяет, сколько уровней пересдачи разрешено: если клиент сам является сервером и пересдаёт карты дальше, именно это поле ограничивает глубину.

Связывание reader и user через одинаковый group

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

Если у вас несколько reader из разных источников, можно дать им разные группы и управлять доступом: одному клиенту — одна группа карт, другому — другая.

cccmaxhops и cccreshare при реле далее по цепочке

При построении цепочки важно согласовать оба параметра. cccmaxhops в oscam.server — сколько хопов принимаем от вышестоящего. cccreshare в oscam.user — сколько разрешаем пересдавать нашим клиентам.

Если вышестоящий сервер ограничивает cccreshare = 1, то даже с большим cccmaxhops у нас карты будут только первого уровня. Это ограничение со стороны источника, обойти его нельзя.

Пример двухзвенной цепочки: источник → прокси → конечный клиент

Схема: Источник (CCcam, порт 12000) → Прокси OScam → Клиент (OScam/CCcam)

На прокси-сервере в oscam.server:

[reader]
label             = source_server
protocol          = cccam
device            = source.example.com,12000
user              = proxyuser
password          = proxypass
group             = 1
cccmaxhops        = 8
ccckeepalive      = 1
reconnecttimeout  = 30
inactivitytimeout = 60
audisabled        = 1

В oscam.user на том же прокси-сервере:

[account]
user          = endclient
password      = endpass
group         = 1
cccreshare    = 5

Клиент подключается к прокси по его IP и CCcam-порту (тот, что прописан в oscam.conf в секции [cccam], параметр port). Прокси принимает ECM-запрос от клиента, передаёт на источник, получает CW, возвращает клиенту.

При двойном NAT — если прокси-сервер сам за роутером — нужен проброс порта на роутере. Входящие клиенты должны доставать до прокси, иначе connection refused.

Маршрутизация трафика OScam через внешний прокси/VPN

Если задача — скрыть реальный IP сервера от вышестоящего источника, прокси для OScam на уровне приложения здесь не поможет. Нужно заворачивать трафик на уровне ОС.

Почему встроенного SOCKS5 для card-протоколов нет

OScam открывает TCP-соединения напрямую, без какого-либо прокси-слоя в коде. Разработчики не реализовывали SOCKS5 для newcamd/cccam — просто не было такой задачи в дизайне. Так что все инструкции вида «пропишите SOCKS5 в OScam» — это либо про что-то другое, либо неработающий совет.

Обёртка через redsocks/iptables для принудительного проксирования

redsocks принимает TCP-трафик и перенаправляет его через SOCKS5 или HTTP-прокси. Связка выглядит так: iptables перехватывает исходящий трафик от процесса oscam на нужные порты и перенаправляет на локальный порт redsocks, а тот уже туннелирует через внешний прокси.

Пример правила iptables (для исходящего трафика на порт 12000):

iptables -t nat -A OUTPUT -p tcp --dport 12000 -j REDIRECT --to-port 12345

Где 12345 — локальный порт redsocks. Это грубый пример; в реальной установке нужно фильтровать по UID процесса oscam или по конкретным целевым IP.

Альтернатива: туннель через VPN-интерфейс на уровне ОС

Проще и надёжнее — поднять WireGuard или OpenVPN, добавить маршрут для IP-адреса вышестоящего сервера через VPN-интерфейс. Тогда весь трафик к источнику идёт через туннель автоматически, без iptables-правил.

Осторожно: если VPN-провайдер блокирует нестандартный порт 12000 (такое бывает на дешёвых коммерческих VPN), соединение не поднимется. Проверяйте проходимость порта через nc -vz upstream.example.com 12000 с VPN-адреса перед тем, как перестраивать маршрутизацию.

httpport и веб-интерфейс OScam за reverse-proxy (nginx)

Веб-интерфейс OScam слушает на порту, заданном в oscam.conf — обычно httpport = 8888. Его можно и нужно прятать за nginx с TLS и basic-auth.

Минимальный блок в конфиге nginx:

location /oscam/ {
    proxy_pass http://127.0.0.1:8888/;
    proxy_set_header Host $host;
    auth_basic "OScam";
    auth_basic_user_file /etc/nginx/.htpasswd;
}

TLS-сертификат — Let's Encrypt через certbot, это занимает две минуты. Снаружи будет виден только 443-й порт nginx, порт 8888 остаётся недоступным извне.

Диагностика и типичные ошибки прокси-соединения

Большинство проблем с прокси для OScam диагностируются за 10 минут, если знать, куда смотреть. Главное — включить нормальный уровень логирования.

Чтение oscam.log: статусы CONNECTED, CARDOK, no matching

Уровень логирования задаётся в oscam.conf в секции [global]: параметр loglevel. Значение 8 даёт полный debug. Можно также запустить OScam с флагом -d 8 прямо из командной строки.

Что искать в логе:

• CONNECTED — reader успешно подключился к вышестоящему серверу
• CARDOK — карты получены и доступны
• no matching reader — ECM-запрос пришёл, но ни один reader не смог его обработать. Обычно проблема с group или с тем, что нужная карта вообще не пришла от источника
• disconnected с последующим reconnecting — нормальный цикл, если не слишком частый

Ошибка «cmd05» и несовпадение версий CCcam

cmd05 в логе — это ошибка handshake CCcam-протокола. Чаще всего причина — несовпадение cccversion между вашим proxy-reader и вышестоящим сервером. Если источник ожидает CCcam 2.3.0, а у вас прописано 2.1.4, рукопожатие может не состояться.

Попробуйте значения 2.3.0, 2.2.1, 2.1.4 — какое принимает источник. Иногда помогает убрать параметр вообще и дать OScam согласовать версию самостоятельно.

ECM timeout и превышение допустимой задержки в цепочке

Каждый хоп в цепочке добавляет сетевую задержку. Типичный лимит ECM timeout на приёмнике — от 3000 до 6000 мс. При двух-трёх промежуточных серверах с ping 80–100 мс каждый, сумма легко перевалит за лимит.

Решение: сокращать цепочку, выбирать серверы с минимальным ping, и проверять ecmwhitelist / ecmcachedenabled в oscam.conf — кэш ECM снижает нагрузку на повторные запросы.

Loop detection и конфликт nodeid

CCcam-протокол защищается от петель: если одна и та же карта вернётся на сервер, который уже её отдал, соединение разрывается. Идентификатор сервера — nodeid, он задаётся в oscam.conf в секции [cccam].

Если два разных OScam-сервера в цепочке имеют одинаковый nodeid (например, оба использовали дефолтное значение), source-сервер думает, что это петля, и отключает один из них. Задайте уникальный nodeid на каждом сервере явно: 16 hex-символов, например nodeid = A1B2C3D4E5F60001.

Проверка портов через telnet/nc и tcpdump

Перед тем как копаться в конфигах, убедитесь, что порт вообще доступен:

# Проверка доступности порта
nc -vz upstream.example.com 12000

# Или через telnet
telnet upstream.example.com 12000

# Захват трафика на порту 12000
tcpdump -i any -n port 12000

tcpdump покажет, идут ли пакеты вообще. Если nc зависает без ответа — порт закрыт фаерволом или NAT не пробит. Если соединение устанавливается, но OScam сразу отключается — проблема в протоколе или аутентификации.

При тестировании цепочки проверяйте каждое звено отдельно: сначала прокси → источник, потом клиент → прокси. Пытаться отладить сразу всю цепочку — потеря времени.