OScam CacheEx: настройка обмена кэшем (2026)

OScam cacheex обмен кэшем — одна из самых полезных функций, которую большинство пользователей либо не трогают вообще, либо настраивают вкривь. Я видел конфиги, где оба пира сидят в режиме cacheex=2 и ждут друг от друга данных, которые никто не отдаёт. Классика.

В этой статье разберём всё по порядку: что такое CacheEx, как работают режимы 1, 2 и 3, где именно в конфигах это прописывать, и как понять по логам, что обмен вообще идёт.

Что такое CacheEx и зачем нужен обмен кэшем в OScam

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

Принцип работы кэша контроль-слов (CW) в OScam

Когда ваш OScam расшифровывает ECM-запрос через карту, полученное контроль-слово (CW) сохраняется в локальном кэше. CacheEx позволяет передать это уже готовое CW соседнему серверу — по хэшу ECM-пакета. Сосед видит тот же ECM, лезет в кэш, находит CW и отдаёт его клиенту мгновенно, без обращения к карте.

Результат: ноль нагрузки на карту при попадании в кэш, отсутствие freeze, задержка ответа — миллисекунды вместо 300–800 мс через ридер.

Чем CacheEx отличается от обычного шаринга через ридер

Через обычный ридер (cs378x, cccam, newcamd) сервер пересылает сам ECM-запрос на удалённую карту и ждёт расшифровки. Нагрузка на карту есть, задержка есть, и каждый запрос уходит в сеть.

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

Cache Sharing Protocol (CSP) и хэши ECM

CSP (Cache Sharing Protocol) — внутренний протокол OScam для передачи CW между узлами. Каждый ECM-пакет имеет хэш (SHA-1 от содержимого). Когда два сервера смотрят один и тот же транспондер, они генерируют идентичные хэши ECM — и CW можно передать без пересылки самого ECM.

Порт для CSP задаётся отдельно в секции [cache] файла oscam.conf. По умолчанию OScam CSP не включён — надо прописывать руками.

Режимы CacheEx: cacheex 1, 2 и 3 — кто отдаёт, кто принимает

Вот где большинство гайдов просто копируют конфиг, не объясняя направление. А без понимания направления настройка превращается в лотерею.

cacheex = 1 — режим источника (отдаёт свой кэш)

Узел с cacheex=1 в блоке [reader] или [account] — это отправитель. Он берёт CW из своего локального кэша и пушит их в сторону пира. Сам при этом от пира ничего не принимает.

Используется на стороне, у которой есть живые карты и свежий кэш, и которая хочет его раздавать.

cacheex = 2 — режим получателя/слушателя

Узел с cacheex=2 принимает CW от пира, но сам ничего не отправляет в обратную сторону. Это слушатель. Он накапливает чужой кэш и отдаёт его своим локальным клиентам.

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

cacheex = 3 — pull-режим (запрос кэша по требованию)

Режим 3 — это pull: узел сам запрашивает CW у пира, когда нужна расшифровка. Не ждёт push, а спрашивает. Менее распространён, подходит для сценариев с нестабильным соединением или когда нет смысла гнать постоянный поток CW.

На практике pull создаёт чуть большую задержку, чем push-режим (связка 1+2), потому что запрос идёт по требованию, а не заранее.

Направление обмена в связке двух узлов

Вот матрица, которую нигде нормально не публикуют:

Узел A (reader на B)	Узел B (account для A)	Результат
cacheex=1	cacheex=2	A → B (A отдаёт, B получает)
cacheex=2	cacheex=1	B → A (B отдаёт, A получает)
cacheex=1	cacheex=1	Оба отдают, никто не принимает — трафик идёт впустую
cacheex=2	cacheex=2	Оба ждут — обмена нет
cacheex=3	cacheex=3	Pull с обеих сторон — может работать, но нагружает канал

Для двустороннего обмена нужно два ридера/аккаунта между парой серверов: один с 1+2, второй с 2+1. Или использовать режим 3 с обеих сторон, но с грамотными фильтрами.

Настройка конфигов: oscam.conf, oscam.server, oscam.user

Пути к конфигам зависят от сборки и системы. Наиболее распространённые варианты:

• /etc/tuxbox/config/oscam/ — старые Enigma2-боксы
• /var/keys/ — многие современные сборки
• /etc/oscam/ — Debian/Ubuntu-пакеты
• /usr/local/etc/oscam/ — ручная сборка из исходников

Файлы: oscam.conf, oscam.server, oscam.user.

Секция [cache] в oscam.conf (csp, wait_time, max_time)

Включение CSP и базовые параметры кэша:

[cache]
maxcachetime = 15
cacheex_wait_time = 300
cacheex_maxhop = 2

[csp]
port = 15000
allow = 192.168.1.0/24,10.0.0.5

cacheex_wait_time = 300 — OScam будет ждать 300 мс входящего CW из кэша перед тем, как отправить запрос на локальную карту. Слишком большое значение вызовет freeze, слишком маленькое — нагрузку на карту. Обычно 200–400 мс — нормальный баланс для спутника.

maxcachetime = 15 — время жизни CW в кэше в секундах. CW для большинства спутниковых провайдеров меняется каждые 10 секунд, так что 15 — разумный запас.

Параметры в [reader]: cacheex, cacheex_maxhop, cacheex_ecm_filter

В oscam.server, блок ридера-пира выглядит так:

[reader]
label = peer_server_A
protocol = cs378x
device = 10.0.0.5,15000
user = myuser
password = mypass
cacheex = 1
cacheex_maxhop = 2
cacheex_ecm_filter = /etc/oscam/cacheex_filter.txt

cacheex_maxhop = 2 означает, что CW, пришедшие с двумя прыжками, не будут пересылаться дальше. Устанавливайте 1–2 для конечного узла, не больше.

Параметры в [account] для входящих CSP-пиров

В oscam.user для входящего пира:

[account]
user = peer_account
pwd = secretpass
cacheex = 2
cacheex_maxhop = 2
cacheex_ecm_filter = /etc/oscam/cacheex_filter.txt

Режим у аккаунта должен быть зеркальным по отношению к тому, что прописано у пира в его ридере. Если пир подключается к вам с cacheex=1 (отдаёт), ваш аккаунт должен стоять на cacheex=2 (получает).

Открытие порта и протокол cs378x/CSP

Порт в [csp] — произвольный, согласованный с пиром. Популярные значения: 15000, 16000, 12000. Главное — открыть его в firewall:

iptables -A INPUT -p tcp --dport 15000 -s 10.0.0.5 -j ACCEPT

Если пир за NAT с динамическим IP — об этом ниже, в разделе про диагностику. Для применения изменений конфига без полного рестарта используется:

kill -HUP $(pidof oscam)

Или через webif на порту 8888 (по умолчанию): Readers → Reload.

Фильтрация и контроль трафика кэша

Без фильтрации CacheEx-узел может превратиться в помойку: принимать мусорные хэши от ненадёжных пиров, гонять трафик по CAIDам, которые вам вообще не нужны, или создавать петли в кольцевых топологиях.

cacheex_maxhop — ограничение прыжков

Каждое CW при передаче несёт счётчик прыжков (hop count). cacheex_maxhop = 1 значит: принять только CW, которые пришли непосредственно от источника, без промежуточных узлов. Это жёсткая защита от лавинного распространения.

Сценарий: три сервера в кольце, у всех maxhop=5. CW начинает ходить по кругу и размножаться. Счётчики got растут, реальных hit нет, трафик растёт. Решение: maxhop=1 или maxhop=2 на конечных узлах.

Фильтр по CAID/provider (cacheex_ecm_filter)

Файл фильтра — простой текстовый список, по одной записи на строку:

# Формат: CAID:ProviderID:ServiceID (0 = любой)
0500:000000:0
1810:000000:0
09C4:000001:0

Путь прописывается в параметре cacheex_ecm_filter в [reader] или [account]. OScam будет принимать или отправлять CW только для указанных CAID/provider-комбинаций. Всё остальное — в мусор.

csp_ecm_filter и защита от мусорных хэшей

В секции [csp] можно добавить csp_ecm_filter — тот же формат файла, но применяется на уровне входящих CSP-соединений ещё до разбора содержимого. Это первая линия защиты.

Fake CW — реальная проблема в открытых CacheEx-сетях. Подделанное CW попадает в кэш, раздаётся клиентам, даёт freeze. Единственная надёжная защита — обмениваться только с теми, кому доверяете, и жёстко фильтровать по CAID.

Ограничение односторонней отдачи (no_wait_time / drop_csp)

Параметр cacheex_wait_time = 0 в [reader] или [account] отключает ожидание кэша для конкретного пира — OScam сразу идёт на карту. Используется, если пир ненадёжен или даёт большую задержку.

drop_csp = 1 в блоке аккаунта запрещает конкретному пиру получать CW от вас через CSP, даже если глобально CSP включён. Удобно для ограничения отдачи конкретному ненадёжному партнёру.

Диагностика обмена кэшем: webif, логи и счётчики

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

Раздел Cache Exchange в веб-интерфейсе

Webif по умолчанию на порту 8888. Раздел Users → выберите аккаунт пира, колонки CacheEx покажут:

• PUSH — сколько CW вы отправили этому пиру
• GOT — сколько CW вы получили от пира
• HIT — сколько из полученных CW реально использовали (клиент запросил, нашли в кэше)

Если GOT=0 — проблема в направлении или подключении. Если GOT>0 но HIT=0 — получаете CW, но они не совпадают с реальными запросами: расхождение CAID, провайдера или хэшей.

Счётчики CACHEEX, hit/got/push в логах

В oscam.log при включённом дебаге (-d 64 или -d 255) будут строки вида:

2026/03/15 14:22:31 c  (cacheex) got pushed CW from peer_server_A (CAID 0500, hop 1)
2026/03/15 14:22:31 c  (cacheex) found in cache CAID 0500 prov 000000 svc 1234
2026/03/15 14:22:35 c  (cacheex) push CW to peer_account CAID 0500

"got pushed" — приняли CW от пира. "found in cache" — клиент получил CW из кэша, не с карты. Если видите только "got pushed" без "found in cache" — CW есть, но не используются.

Включать debug-уровень только на время отладки. -d 64 для CacheEx-специфичного вывода, -d 255 для всего — файл лога растёт очень быстро.

Анализ задержек и cacheex_wait_time

Если клиенты периодически получают freeze при наличии попаданий в кэш — возможно, wait_time слишком мал. OScam уходит на карту раньше, чем CW от пира успевает дойти.

Смотрите в логах временну́ю метку между ECM-запросом и "found in cache". Если разница 350 мс, а wait_time стоит 200 мс — поднимите до 400–450 мс. Но помните: слишком большое значение увеличит задержку для запросов, которых нет в кэше.

Проверка зеркальности настроек у пира

Самый частый источник проблем — несимметричная настройка. Попросите пира прислать его блок [reader] и [account] для вас. Проверьте:

• Режимы cacheex зеркальные (у него 1 — у вас 2, и наоборот)
• Фильтры по CAID не исключают нужные каналы
• Порт открыт с обеих сторон
• Время на серверах синхронизировано (разница >2 секунд ломает актуальность CW)

Расхождение системного времени — неочевидная причина проблем. CW действует ~10 секунд. Если один сервер отстаёт на 5 секунд, CW может прийти уже устаревшим. Проверяйте через ntpdate или chronyc tracking.

Отдельная история — пир за NAT с динамическим IP. CW от него к вам идут нормально (он инициирует соединение), но ваши CW к нему не возвращаются, если адрес изменился. Здесь помогает использование DDNS-имени вместо IP в device= и установка keepalive на соединении.

Ещё один нюанс: версии OScam. До ревизии примерно r11550 параметр назывался иначе или принимал другие значения. Если пир сидит на старой сборке, некоторые параметры типа cacheex_ecm_filter у него могут отсутствовать вообще. Это надо уточнять при настройке.

И последнее про дубли: если один CAID отдаётся двумя разными пирами, вы можете получать GOT от обоих, но реальный HIT даст только первый пришедший CW. Второй дублируется в кэше, статистика пухнет, а пользы от второго пира — ноль. Решение: или разделить CAIDы по пирам через фильтр, или оставить одного пира на этот CAID.

Правильно настроенный OScam cacheex обмен кэшем в итоге выглядит так: GOT растёт вместе с HIT, PUSH уходит к пиру, freeze исчезают, нагрузка на карту падает в разы. Если картина другая — возвращайтесь к матрице режимов и логам.