Cómo comprobar si el DNS está provocando fallos de conexión en Plex
Demuestra primero la conectividad IP directa; investiga el DNS únicamente cuando Plex funciona mediante la dirección, pero falla con el nombre de host habitual, el descubrimiento de la aplicación o la ruta de conexión segura.
El DNS puede hacer que Plex falle debido a un resolvedor proporcionado por el router, al filtrado de Pi-hole o Unbound, a respuestas obsoletas en el cliente, a reglas de DNS dividido o a la protección contra rebind alrededor de `plex.direct`. Estos fallos pueden parecer una interrupción del servidor aunque el servicio sea accesible mediante IP. Usa un cliente con fallos, una dirección de servidor conocida y un resolvedor alternativo para aislar la resolución de nombres antes de modificar el reenvío de puertos, las bibliotecas o la configuración de los contenedores.
Demuestra la conectividad IP antes de probar el DNS
Usa la dirección privada conocida del servidor Plex en la LAN y confirma que el host es accesible y que el puerto de Plex responde. Si la ruta IP falla, el DNS no es la causa principal. Corrige el enrutamiento, el firewall, el direccionamiento del host o la disponibilidad del servicio antes de cambiar la configuración del resolvedor.
Un diagnóstico de DNS solo resulta creíble después de que funcione el acceso directo mediante IP. Si el mismo cliente accede a Plex por dirección, pero no mediante su nombre habitual o su ruta segura, el comportamiento del resolvedor se convierte en una rama de diagnóstico clara.
Registra la IP que funciona y el nombre de host que falla, o el comportamiento problemático de la aplicación. Si ambos fallan, detén la prueba de DNS. Si la IP funciona y la ruta habitual de Plex falla, ya tienes una rama clara para comprobar la resolución, el nombre seguro o el rebind.
Compara las respuestas del resolvedor y el comportamiento del rebind
Consulta el nombre de host que falla mediante el resolvedor que realmente usa el cliente y compara la respuesta con la de un cliente que funcione correctamente o con la de un resolvedor de confianza temporal. Si las respuestas difieren, revisa el DNS asignado por DHCP, las reescrituras locales y el filtrado antes de modificar Plex o NAT.
`plex.direct` puede resolverse a la dirección privada de un servidor, por lo que la protección contra el DNS rebind puede bloquear la respuesta aunque el propio host de Plex esté funcionando correctamente. Comprueba los registros del resolvedor para detectar consultas relacionadas con Plex bloqueadas o reescritas, en lugar de desactivar globalmente la protección contra el rebind.
Omite temporalmente un resolvedor para un solo cliente, repite la misma solicitud de Plex y conserva únicamente el cambio más específico que corrija la ruta fallida. Si el resolvedor alternativo no produce ninguna diferencia, revierte la prueba y continúa con los certificados, el descubrimiento de la aplicación, el firewall o el enrutamiento remoto.
Si ambos resolvedores devuelven la misma respuesta y la prueba de control mediante IP directa sigue funcionando, es menos probable que el DNS sea el fallo activo. Conserva ese resultado y pasa a validar los certificados, comprobar el descubrimiento de la aplicación, revisar la política del firewall o analizar la ruta remota, en lugar de añadir más excepciones al resolvedor.
Separa los fallos del DNS local de los fallos de acceso remoto
Un problema de DNS en la LAN puede hacer que los clientes locales consideren que el servidor es indirecto o no está disponible, mientras que el acceso remoto externo sigue funcionando. También puede ocurrir lo contrario: los nombres locales se resuelven correctamente, pero el puerto público o la ruta CGNAT están bloqueados. Probar en ambas direcciones evita que un síntoma oculte al otro.
Una excepción para el dominio privado puede corregir el comportamiento del resolvedor local, pero no crea una ruta de entrada desde Internet; un fallo exclusivo del acceso remoto sigue correspondiendo a la topología de NAT, del firewall o del proveedor de Internet.
Prueba un cliente de la LAN con el DNS normal, el mismo cliente con un resolvedor alternativo temporal y un cliente remoto mediante datos móviles. Anota qué celdas de la matriz funcionan. Ese patrón suele indicar si el DNS es local, remoto o no está relacionado.
Conserva la solución solo si resiste los cambios de caché y reinicio
Las soluciones de DNS pueden parecer efectivas porque la caché de un cliente conserva una respuesta antigua o porque sigue activo un desvío temporal del resolvedor. Vacía o caduca la caché correspondiente, renueva la configuración de red del cliente y reinicia una vez el resolvedor o el router antes de declarar resuelto el problema.
La configuración del DNS rebind y de NAT puede solaparse, así que documenta qué cambio único resuelve la prueba fallida en lugar de conservar varias excepciones innecesarias.
Si el DNS solo deja al descubierto un cambio mayor en el router o la subred, la ruta de acceso remoto tras un cambio de router se convierte en la siguiente rama, una vez restaurada la configuración normal de los clientes.
Productos recomendados
Soporte y Consejos
Más para leer
¿Puede Plex compartir una GPU con otro contenedor de Docker?
Plex y otro contenedor suelen poder acceder a la misma GPU, pero debes probar la compatibilidad de los controladores, la asignación de dispositivos, la...
Cómo saber si un error de Plex proviene del cliente o del servidor
Reproduce el mismo elemento en otro cliente, compara la ruta de la sesión y recopila pruebas del servidor solo después de que el alcance...
Cómo configurar la caché de Plex y el almacenamiento temporal para la transcodificación
Protege el estado persistente de Plex mientras colocas los archivos temporales de transcodificación en un almacenamiento local adecuado; después, verifica la limpieza, el espacio...
