Mejor configuración de OSCam: Guía de configuración óptima (2026)

Si llevas ejecutando OSCam más de una semana, ya sabes que las configuraciones predeterminadas que circulan por los foros son un desastre. La mitad se escribieron para una configuración de tarjeta que ya nadie usa, y la otra mitad copian y pegan valores sin explicar qué hacen en realidad. Esta guía repasa lo que yo llamaría la mejor configuración de OSCam para un lector estable y de baja latencia en 2026 — no el número más rápido posible en una pantalla de benchmark, sino una configuración que sobrevive una semana de tráfico real sin que tengas que conectarte por SSH a las 2 de la madrugada para reiniciar el servicio.

Doy por hecho que ya tienes OSCam compilado y funcionando. Esto no es una publicación de "qué es el cardsharing". Se trata de ajustar oscam.conf, oscam.server, oscam.user y oscam.services para que los tiempos de ECM se mantengan bajos y tus lectores no se caigan bajo carga.

Qué significa realmente la 'mejor' configuración de OSCam

Esto es algo que nadie te dice de entrada: no existe una única mejor configuración de OSCam que puedas colocar en cualquier equipo y olvidarte. Una Raspberry Pi que ejecuta una sola tarjeta local se comporta de forma completamente distinta a un VPS que hace peering con seis socios de cache-ex simultáneamente mediante newcamd y CCcam. Los ajustes "óptimos" para uno son activamente perjudiciales en el otro — subir los hilos de cache-ex en un STB de 512MB simplemente hará que tu proceso muera por falta de memoria (OOM).

Optimizar la velocidad de decodificación frente a la estabilidad

Un tiempo de ECM bajo se ve genial en una gráfica, pero perseguirlo con demasiada agresividad es la forma en que la gente termina con configuraciones inestables. Si ajustas los tiempos de espera demasiado justos para recortar 200ms del tiempo de decodificación, obtendrás un cambio prematuro de lector y pérdida de imagen en cuanto tu red tenga un fallo. Una configuración realmente buena equilibra ambas cosas — lo suficientemente rápida para que el cambio de canal se sienta instantáneo, lo suficientemente estable para que no recibas tickets de soporte por congelamientos en horario de máxima audiencia.

Por qué no existe una única configuración universal

Tu hardware, tu número de lectores y tu combinación de protocolos (tarjeta local frente a CCcam frente a newcamd frente a gbox) cambian todo lo que parece "óptimo". Una configuración ajustada para una sola tarjeta local DVB-S2 sin ningún tipo de compartición no debería parecerse en nada a una construida para un equipo con cinco lectores balanceados en carga que extraen de múltiples fuentes ascendentes. Cualquiera que te entregue un único oscam.conf universal sin preguntarte por tu configuración te está dando un punto de partida, no un producto terminado.

Los cuatro archivos principales y sus funciones

Todo reside en cuatro archivos que trabajan juntos.oscam.conf gestiona el comportamiento global — registro (logging), tiempos de espera, la interfaz web, el puerto de monitor, anti-cascading.oscam.server define tus lectores: ranuras de tarjeta inteligente local, conexiones proxy a fuentes CCcam o newcamd, pares gbox.oscam.user define quién tiene permiso para conectarse a tu equipo y qué puede ver.oscam.services agrupa CAIDs e idents en paquetes de servicio con nombre que puedes poner en lista blanca o bloquear por lector y por usuario. Si aciertas con la relación entre estos cuatro archivos, la mayoría de las quejas de "sin canales" desaparecen por sí solas.

Configuración global óptima de oscam.conf

En la mayoría de las compilaciones encontrarás oscam.conf en/etc/tuxbox/config/oscam.conf, aunque algunas distribuciones usan/var/keys/ o lo que se haya definido como ConfigDir en el momento de la compilación con--with-configdir. Si no estás seguro, revisa el pie de página de la interfaz web o inicia OSCam con-c /path/to/configpara forzarlo.

[global] configuración de logging y nice/pidfile

Aquí tienes un bloque [global] sensato que uso como base:

[global]

maxlogsize=50 evita que tu archivo de log se infle más allá de 50KB antes de rotar — en hardware STB con escrituras de flash limitadas, eso importa más de lo que la gente cree.nice=-1 le da a OSCam un pequeño impulso de prioridad de programación sobre otros procesos, lo cual ayuda al tiempo de respuesta de ECM en cajas que hacen doble función.preferlocalcards=1 le indica a OSCam que siempre intente usar una tarjeta local antes de recurrir a un lector de red, que es exactamente lo que quieres si eres dueño de la tarjeta y solo usas peers como respaldo.

[webif] habilitando la interfaz web en el puerto 8888

[webif]

El puerto 8888 es el predeterminado de OSCam y no hay razón para cambiarlo a menos que algo más en la caja ya lo esté usando. Lo que realmente importa eshttpallowed — restríngelo a tu rango de LAN. Dejar la interfaz web abierta a 0.0.0.0 en una caja con puertos expuestos a internet es cómo la gente termina con sus credenciales de tarjeta robadas. Volveré a esto en el FAQ de seguridad, pero trátalo como innegociable.

Ajuste de [monitor] y [anticasc]

[monitor]

El anti-cascading detecta cuando una sola tarjeta se está compartiendo con demasiados clientes simultáneos y la limita o bloquea. Es genuinamente útil en una caja compartida con múltiples usuarios no confiables, pero en hardware STB con poca RAM añade una sobrecarga constante por una verificación que probablemente no necesitas si eres el único cliente. Si estás corriendo en algo como una Vu+ de 512MB o una caja similar, dejaanticasc deshabilitado y confía enuniq en oscam.user en su lugar — es más económico, y hace la mayor parte del mismo trabajo para una configuración de un solo propietario.

Valores de clienttimeout, fallbacktimeout y cachedelay

clienttimeout=15000

clienttimeout (en milisegundos) es cuánto tiempo espera OSCam una respuesta antes de rendirse por completo con la solicitud de ECM — 15000ms es un límite razonable.fallbacktimeout es el que la gente configura mal constantemente. Controla cuánto tiempo espera OSCam en el lector primario antes de intentar un lector de respaldo para el mismo ECM. Configúralo demasiado bajo (digamos, menos de 1000ms) y obtienes un fallback prematuro — OSCam salta a un lector de respaldo antes de que la tarjeta primaria haya tenido siquiera una oportunidad justa, desperdiciando ancho de banda y ocasionalmente causando solicitudes duplicadas de CW. Configúralo demasiado alto y un lector primario con problemas estancará toda tu cadena antes de que el fallback entre en acción. 2500ms es un buen punto medio para la mayoría de las configuraciones de tarjeta local más respaldo; ajústalo a valores más cercanos a 1500ms solo si el tiempo promedio de ECM de tu lector primario está consistentemente por debajo de 500ms.

Configurando lectores en oscam.server

Aquí es donde ocurre la mayor parte del ajuste real. Cada[reader] bloque define una tarjeta o una conexión proxy.

Lector de tarjeta inteligente local (device, mhz, cardmhz)

[reader]

mhz es la frecuencia de reloj que OSCam usa para comunicarse con el hardware del lector;cardmhz es la frecuencia de reloj que se negocia con la tarjeta misma. La mayoría de las tarjetas funcionan bien con el estándar ISO de base de 357/357. Algunas tarjetas admiten lecturas más rápidas a 368, 369, o incluso 600 — pero si configuras cardmhz con un valor que la tarjeta no soporta realmente, obtendrás un bucle de inicialización de tarjeta donde el lector se reinicia una y otra vez en lugar de estabilizarse en el ATR. Si ves fallos repetidos de "card init" en el log justo después de un reinicio, vuelve primero a 357/357, confirma que inicializa correctamente, y solo entonces experimenta hacia arriba.

Agregar lectores proxy cccam/newcamd/gbox

[reader]

Usa IPs de marcador de posición como esta al hacer pruebas — nunca escribas de forma fija el nombre de host real de un proveedor en una configuración compartida que publiques. Para lectores newcamd, cambiaprotocol = newcamd y agregakey = con la clave DES, más los ajustes deemmcache si deseas almacenamiento en caché de EMM desde esa fuente.

Filtrado de CAID, ident y services por lector

caid = 1802,1801

disablecrccws=1 omite la verificación CRC en las palabras de control — ocasionalmente necesario para firmware de tarjetas defectuoso que devuelve CWs mal formadas pero válidas, pero déjalo en 0 a menos que hayas confirmado que realmente lo necesitas, ya que también oculta corrupción real.ecmwhitelist restringe qué PIDs de ECM intentará siquiera el lector, lo que reduce las solicitudes desperdiciadas en transpondedores con múltiples CAID.

Parámetros group, fallback y cacheex_maxhop

group es el ajuste más malinterpretado de toda la configuración, y lo diré claramente: el número de group en un lector debe coincidir con el número de group en un usuario para que ese usuario pueda ver alguna vez las tarjetas de ese lector. Sin error, sin advertencia — el cliente simplemente se conecta y no recibe nada. Si recuerdas una sola cosa de este artículo, que sea esa.cacheex_maxhop limita cuántos saltos puede recorrer una CW compartida a través de tu red de pares antes de ser descartada — más sobre esto en la siguiente sección, porque configurarlo mal es como las redes cache-ex terminan convirtiéndose en tormentas de CW duplicadas.

Acceso de clientes y permisos en oscam.user

Definición de usuarios, mapeo de grupos y AU

[account]

De nuevo —group = 1 aquí debe coincidir con el grupo del lector para que este usuario pueda ver algo de esa tarjeta.au (auto-update) debe apuntar exactamente a una etiqueta de lector de confianza y, honestamente, solo un cliente por tarjeta debería tener AU habilitado. Si habilitas AU en la misma tarjeta para dos cuentas de cliente diferentes, obtienes escrituras EMM simultáneas en la tarjeta desde dos direcciones — es una forma rápida de corromper el estado interno de la tarjeta o causar conflictos de escritura que se manifiestan como fallos de decodificación aleatorios días después.

caidtab, betatunnel y services por usuario

caidtab = 1802:0500,1801:0000

caidtab restringe a un usuario específico a CAIDs específicos, incluso si el lector al que está asignado tiene más.betatunnel importa en entornos con CAID mixtos — si tienes una tarjeta Nagra (1801/1802) y necesitas decodificar de forma cruzada canales marcados como Seca que en realidad llevan la misma señal, betatunnel remapea el CAID sobre la marcha para que el receptor acepte el CW. Sin él, las configuraciones mixtas Nagra/Seca simplemente fallan en silencio al decodificar ciertos canales, aunque la tarjeta pueda técnicamente producir un CW válido.

Limitación de velocidad con cccmaxhops y sleep

cccmaxhops = 2

cccmaxhops limita hasta dónde puede propagarse un share de CCcam a través de reshares posteriores — mantenlo en 2 a menos que tengas una razón específica para dejar que las tarjetas viajen más lejos, ya que cada salto adicional añade latencia y riesgo de carga.sleep desconecta a los clientes inactivos después de N minutos, lo que libera espacios de conexión en un servidor ocupado en lugar de mantener sesiones zombis.

Asegurar cuentas y deshabilitar usuarios no utilizados

uniq = 1 impide que la misma cuenta inicie sesión desde dos lugares simultáneamente — configúralo en cada cuenta a menos que tengas una razón específica para no hacerlo, porque las credenciales compartidas son la forma más común en que se abusa de una cuenta. Para las cuentas que no estás usando actualmente, no las elimines — configuraenabled = 0 en su lugar, para conservar el historial de configuración sin dejar una puerta activa abierta.

cache-ex, Emparejamiento (Peering) y Ajuste de Rendimiento

Esta es la parte que la mayoría de las guías omiten por completo, y honestamente es la diferencia entre una buena configuración y la mejor configuración de OSCam para un sistema con múltiples lectores. Cache-ex es lo que permite que los servidores OSCam compartan entre sí las palabras de control ya decodificadas, en lugar de que cada servidor tenga que consultar su propia tarjeta para el mismo ECM.

Modos 1, 2 y 3 de cacheex explicados

El modo 1 es solo caché — el lector almacena los CW que ve pero no los envía ni los solicita activamente. El modo 2 envía CW hacia los peers (tú eres la fuente). El modo 3 recibe CW de los peers (tú eres el consumidor). Si inviertes la dirección, o bien inundarás a los peers con CW que no pidieron, o te quedarás esperando en un lector de "pull" que no tiene a nadie enviándole realmente nada. Configuracacheex = 2 en los lectores que representan tarjetas que posees y quieres compartir, ycacheex = 3en los readers que representan a los peers "upstream" de los que estás consumiendo.

cacheex_maxhop y cómo evitar bucles de caché

Este es un modo de fallo que atrapa a quienes ejecutan tres o más peers: sin uncacheex_maxhop razonable, un CW puede rebotar entre el peer A, B y C repetidamente, con cada equipo retransmitiéndolo como si fuera nuevo. Eso es una tormenta de CW duplicados, y consume ancho de banda y CPU sin ningún beneficio. Manténcacheex_maxhop = 2 como valor predeterminado, y nunca lo configures por encima de 3 en una malla con múltiples peers a menos que controles completamente cada equipo de esa malla y hayas verificado que no hay bucles en la topología.

csp (cache server protocol) y el balanceo de carga con lb_mode

[csp]

lb_mode = 1 activa el balanceador de carga integrado de OSCam entre tus readers, clasificándolos según el tiempo histórico de respuesta ECM.lb_nbest_readers controla cuántos de los readers con mejor rendimiento se prueban en paralelo para un ECM dado — 2 es un valor predeterminado razonable para la mayoría de las configuraciones con más de una fuente viable por CAID.lb_reopen_seconds es el tiempo que un reader marcado como malo permanece apartado antes de que OSCam le dé otra oportunidad; 900 segundos (15 minutos) evita machacar a un reader que simplemente está pasando por un mal momento, a la vez que permite recuperarlo eventualmente.

Reducir los ajustes de tiempo e intervalo de ECM

La página de estadísticas de readers de la interfaz web muestra el tiempo promedio de ECM por reader — esa es tu verdadera herramienta de diagnóstico, no las suposiciones. Si ves fallos de decodificación (la tarjeta no devolvió nada utilizable) frente a timeouts (no volvió nada en absoluto) en proporciones distintas entre readers, eso te indica cosas diferentes: los fallos de decodificación suelen apuntar a discrepancias de CAID/ident o a una tarjeta con problemas, mientras que los timeouts suelen apuntar a latencia de red o a un peer upstream sobrecargado. Observa esa página durante un día antes de empezar a cambiar los valores de timeout a ciegas.

Solución de problemas comunes de configuración de OSCam

La tarjeta no se inicializa (errores de mhz / device)

Si tu registro muestra fallos repetidos de ATR o la tarjeta se reinicia en bucle, comprueba primero la ruta dedevice — un lector USB puede pasar de/dev/ttyUSB0 a/dev/ttyUSB1 tras un reinicio si algo más en el bus cambió de orden. Si la ruta del device es correcta, bajamhz/cardmhz a 357/357 como prueba de referencia.

Cliente se conecta pero ningún canal decodifica

Nueve de cada diez veces esto es el desajuste de grupo que mencioné antes — verifica que la líneagroup del lector coincida con la líneagroup del usuario. Si coinciden y aún así no funciona, revisa oscam.services — es fácil tener el CAID y el grupo correctamente configurados mientras una entrada del archivo de servicios excluye silenciosamente el ident del canal específico, lo cual parece idéntico a un problema de grupo desde el lado del cliente, pero no tiene nada que ver con los permisos.

Imagen congelada y tiempos de ECM altos

Esto casi siempre se debe a quefallbacktimeout está configurado demasiado bajo de forma agresiva, lo que provoca que la cadena de lectores oscile entre el primario y el de respaldo en medio de la transmisión, o a un lector que está genuinamente sobrecargado por demasiados peers de cache-ex simultáneos que tiran de él. Revisa la página de estadísticas del lector en busca de picos en el tiempo de ECM correlacionados con tus horas de mayor uso.

Leer los logs de oscam para encontrar la etapa que falla

Ejecuta OSCam en primer plano con depuración detallada del lector:oscam -b -r 2. Busca en tu log (grep) dos cadenas específicas —"not found (" te indica qué CAID/ident solicitó el cliente que ningún lector pudo servir, y"rejected" te indica que ocurrió un bloqueo de autenticación o de nivel de grupo antes de que la solicitud llegara siquiera a un lector. Estas dos cadenas por sí solas te señalarán la etapa que falla más rápido que leer todo el log de principio a fin.

Nada de esto es exótico; se trata sobre todo de entender lo que realmente hace cada parámetro en lugar de copiar una configuración a ciegas. Si te llevas una sola cosa de todo esto, que sea que la mejor configuración de OSCam para tu equipo es la que coincide con tu hardware real y tu número de lectores, no la que alguien más pegó en un foro en 2019. Empieza con los valores predeterminados de arriba, observa la página de estadísticas de tus lectores durante unos días y ajusta un valor a la vez a partir de ahí.