Plex se abre localmente, pero falla de forma remota después de cambiar el router

Si Plex sigue abriéndose en la red local, conserva el servidor y reconstruye, en este orden, el direccionamiento, la NAT, el DNS y la ruta de acceso remoto del nuevo router.

Un cambio de router puede asignar al equipo de Plex una dirección privada diferente, eliminar una asignación de puertos antigua, introducir una doble NAT o habilitar un comportamiento de DNS que antes no existía. Estos son cambios en el perímetro de la red, no motivos para volver a escanear los archivos multimedia ni reemplazar la base de datos. Empieza con una prueba de reproducción local, identifica la nueva ruta desde la conexión del ISP hasta Plex y conserva cada cambio solo cuando una prueba externa lo confirme.

Confirma que el fallo solo afecta al acceso remoto

Primero demuestra que Plex funciona correctamente. Abre el servidor desde la red local, reproduce un archivo conocido y confirma que el servidor sigue asociado a tu cuenta y responde. Si el acceso local también falla después del cambio de router, trata primero el problema general de direccionamiento, DNS, firewall o del equipo antes de trabajar en el reenvío desde Internet.

Cuando el acceso remoto falla pero la reproducción en la LAN sigue funcionando, aísla la ruta externa antes de modificar el estado de Plex. Una prueba local correcta significa que la base de datos y el motor de reproducción probablemente no son el primer objetivo de recuperación.

Si la reproducción local funciona, anota la dirección LAN y la puerta de enlace actuales del equipo de Plex. Si recibió una dirección nueva del router de reemplazo, cualquier reserva o regla de reenvío antigua podría apuntar ahora al dispositivo equivocado. Corrige la identidad del equipo antes de cambiar los puertos externos.

Reconstruye la ruta de puertos para el nuevo router

Reemplazar el router invalida el estado NAT anterior aunque el equipo con Plex no haya cambiado. Decide si el nuevo router debe crear la asignación automáticamente o si definirás un puerto público y lo reenviarás a la dirección privada actual del servidor y al puerto de Plex.

Después de reemplazar el router, la coincidencia del puerto público debe corresponder al puerto que el router expone realmente y al puerto que Plex espera.

Aplica un solo método de reenvío y después prueba desde los datos móviles u otra red externa. Si el puerto sigue siendo inaccesible, no crees varias reglas superpuestas. Avanza hacia la conexión ascendente y determina si ahora hay otra NAT o firewall entre este router e Internet.

Comprueba si la nueva topología añadió una doble NAT

Muchos gateways de los ISP combinan las funciones de módem y router. Añadir un router Wi‑Fi nuevo detrás de ese equipo puede crear dos capas NAT donde antes solo había una. Un reenvío en el router interno se detendrá en el gateway externo, a menos que la topología esté en modo puente o ambas capas estén configuradas deliberadamente.

Si dos routers locales están traduciendo el tráfico, ponerlos en modo puente o reenviar en ambas capas puede restaurar una ruta de entrada completa; compara la dirección WAN del nuevo router con la dirección pública para detectar una NAT externa inesperada.

Si controlas ambos dispositivos, elige una sola autoridad de enrutamiento siempre que sea posible. Si el perímetro público está controlado por el ISP y la dirección WAN no coincide con la dirección pública, investiga la CGNAT en lugar de asumir que funcionará otra regla local.

Si la traducción externa pertenece al ISP y no a otro router que controles, deja de tratar el problema como una doble NAT normal. Esa rama se convierte en un problema de CGNAT o de dirección pública, y repetir los reenvíos de puertos en el router interno no creará autoridad en el perímetro del ISP.

Featured

ZimaCube 2 NAS personal en la nube para el hogar

ZimaCube2

$799.00 - $2,499.00

Buy Now

Prueba el DNS y la resolución segura de nombres locales por separado

Un router nuevo también puede cambiar el filtrado de DNS, la protección contra el DNS rebinding, el comportamiento del resolvedor local o los servidores DNS proporcionados por DHCP. Estos cambios pueden hacer que las conexiones seguras de Plex o la detección local se comporten de forma extraña aunque la dirección IP directa del servidor siga abriéndose.

Un resolvedor puede interferir con los nombres locales seguros de Plex cuando el comportamiento de DNS rebinding bloquea el patrón `plex.direct`. Prueba la resolución de nombres antes de desactivar ampliamente las funciones de seguridad.

Desde un cliente de la LAN, compara el acceso mediante la IP privada del servidor con el acceso a través de la aplicación normal de Plex o del nombre de host seguro. Si la IP directa funciona pero la detección basada en nombres falla, mantén la solución dentro del DNS. Si ambos funcionan localmente y solo falla la ruta de Internet, vuelve a comprobar la NAT y el perímetro del ISP.

Acepta la nueva configuración base solo después de probar un reinicio

Un acceso remoto temporalmente correcto puede desaparecer si el equipo recibe otra dirección LAN, el router recrea una asignación automática de forma diferente o la nueva ruta DNS cambia después de renovar la concesión. La fiabilidad requiere que la configuración sobreviva a los reinicios habituales sin reparaciones manuales.

Un plan estable de reconstrucción de red debe conservar la identidad del equipo, el enrutamiento, el DNS y la accesibilidad remota después de un reinicio, en lugar de terminar con un estado correcto puntual.

Reserva la dirección del equipo con Plex o haz que sea estable de otra manera, reinicia una vez el equipo y el router y vuelve a probar la reproducción local y remota. Si la ruta sobrevive, documenta la regla del puerto público, cualquier excepción de DNS y la topología del ISP. Si falla después del reinicio, la recuperación no está completa.