Credenciales rechazadas, "failed to authorize", ningún canal: las 7 causas, de la más tonta a la más seria

Es el mensaje más vago del IPTV: "credenciales rechazadas", "failed to authorize", o simplemente una lista de canales vacía. El servidor ha dicho no, sin decir por qué. Pero los motivos posibles van desde el espacio de más en un copiar y pegar hasta la cuenta baneada por compartirla, y no se arreglan en absoluto de la misma manera. Esta guía los toma por orden de frecuencia, y empieza por la única herramienta que los distingue.

Decidirlo en treinta segundos

Antes de nada, prueba tus credenciales con el comprobador. Le pregunta al servidor de tu proveedor, desde nuestras máquinas, y muestra lo que el servidor responde: estado de la cuenta (activa, caducada, baneada, desactivada), fecha de fin, número de conexiones permitidas, número de canales.

Si el comprobador dice "activa" mientras la app rechaza, el servidor acepta tus credenciales: es la forma en que están introducidas en la app lo que falla. Es el caso más frecuente, y el más rápido de arreglar.

1. Un carácter de más

Las credenciales Xtream Codes son cadenas de letras y cifras generadas por el servidor. Se copian, no se reescriben. Los errores clásicos:

• Un espacio pegado antes o después de la contraseña, invisible en el campo. Las apps de mensajería suelen añadir uno al final de línea.
• Un cero y una O, un 1 y una l confundidos al reescribir. El servidor no perdona.
• Una mayúscula cambiada por el teclado del móvil, que pone en mayúscula el primer carácter de un campo por defecto.

Borra el campo, vuelve a pegar desde el mensaje del proveedor, y comprueba que el cursor queda pegado al último carácter.

2. La información correcta en el campo equivocado

Un acceso IPTV viene en tres formas, y cada una tiene sus campos:

• Xtream Codes: una dirección de servidor, un nombre de usuario, una contraseña. La dirección termina en el puerto, por ejemplo http://servidor.example:8080. Nada después.
• URL M3U: una sola línea, larga, que contiene get.php o termina en .m3u. Va en el campo M3U, no en el campo servidor.
• Portal MAC: una URL de portal y una dirección MAC. Ver el caso 3.

El error típico: pegar la URL M3U completa en el campo "servidor" de un acceso Xtream. El servidor recibe una dirección que ya contiene credenciales, más las credenciales al lado, y rechaza. Otro clásico: pegar http://servidor.example:8080/player_api.php en vez de http://servidor.example:8080. La guía M3U o Xtream Codes detalla lo que contiene cada forma.

Dos detalles que cuentan: el puerto (:8080, :80, :25461, el que dio el proveedor, nunca adivinado) y http o https, copiado tal cual. Un servidor http rechazado en https, y al revés, también da un "rechazado".

3. El portal MAC sin su MAC

Algunos proveedores no usan usuario y contraseña, sino una dirección MAC, con el formato 00:1A:79:XX:XX:XX, que su servidor asocia a tu suscripción. Es la herencia de los decodificadores de salón dedicados, donde la dirección era la del aparato.

Hoy la dirección es una clave como cualquier otra: el proveedor te asigna una, la introduces en la app con la URL del portal. Si el servidor rechaza, la dirección introducida no es la que conoce. Tres casos: una errata, una dirección aún no activada del lado del proveedor, o una dirección ya asociada a otro dispositivo que el proveedor debe liberar. En los tres, él tiene la llave.

4. La suscripción caducó

El caso número 1 del "ayer funcionaba". La fecha de fin pasó, el servidor rechaza todo. El comprobador lo muestra negro sobre blanco, e IPTV Guard te avisa una semana, tres días y un día antes, precisamente para que no pase delante de la tele.

Si acabas de renovar y sigue rechazando, el servidor aún no ha registrado el pago: es frecuente, y se arregla con el proveedor. Nada que cambiar en la app, reintenta sola.

5. La cuenta está baneada o desactivada

El servidor reconoce tu acceso y rechaza igualmente: el proveedor lo ha cortado. El mensaje de la app lo dice explícitamente. Los motivos habituales, por orden:

• El acceso ha circulado. Un amigo, un grupo, un foro. El servidor ve conexiones desde varias ciudades y el proveedor corta, a menudo sin avisar.
• Un impago o una disputa con el revendedor.
• Demasiados dispositivos en poco tiempo, que algunos proveedores interpretan como un uso compartido.

Ninguna app puede levantar un baneo. Es una conversación con el proveedor, y conviene saber cuál de los tres motivos antes de empezarla.

6. El servidor bloquea a la app, no a ti

Caso más raro y más desconcertante: las credenciales son correctas, el comprobador dice activa, pero la app es rechazada. Algunos proveedores cierran el acceso a la API Xtream Codes tras un cortafuegos, dejando abierta solo la lista M3U. Resultado: un acceso Xtream rechazado, lo mismo en M3U aceptado.

IPTV Guard detecta este caso al añadir la lista y cambia solo a M3U, diciéndote lo que cambia: todo funciona, salvo la información que solo da la API, como la fecha de caducidad y el número de conexiones.

7. El servidor se mudó

"Dirección no encontrada" o "tiempo agotado" en una suscripción no caducada: el proveedor cambió de dirección y la tuya apunta a un servidor muerto. No es un rechazo, es un silencio. La guía mi proveedor cambió de dirección explica cómo actualizar sin perder favoritos y reanudaciones.

El falso primo: el límite de conexiones

Algunas apps muestran "failed to authorize" cuando el servidor rechaza una plaza porque la suscripción ya está en uso en otro sitio. No es un problema de credenciales, y reescribirlas cien veces no cambiará nada. La señal: funciona a veces, falla otras, según lo que hagan los demás dispositivos de la casa. La guía sobre el límite de conexiones explica cómo recuperar tu plaza.

Lo que no hay que hacer

• Reinstalar la app. Ninguno de los siete casos está en la app.
• Crear una lista nueva en cada intento. Corrige la que existe: tus favoritos y reanudaciones están ligados a ella.
• Pedir credenciales nuevas antes de probar las antiguas con el comprobador. Un proveedor que genera nuevas a cada llamada nunca buscará la causa.