El reenvío de puertos tiene fama de ser confuso. Aparece en todas las guías de juegos, en todos los tutoriales de servidores domésticos y en todas las guías de configuración de cámaras IP, generalmente ocultos en la configuración del enrutador con campos crípticos y sin explicación de lo que realmente hace.

Actualizado el 8 de octubre de 2026: agregó una lista de verificación ordenada de solución de problemas y enlaces a las guías CGNAT, NAT doble y NAT de horquilla.

Esta guía omite la jerga y explica lo que realmente está sucediendo, para que puedas tomar la decisión correcta sobre si la necesitas y configurarla correctamente cuando la necesites.

El modelo mental: su enrutador es recepcionista

Su enrutador se encuentra entre su red doméstica e Internet. Cada dispositivo de su casa (teléfono, computadora portátil, televisor inteligente, consola de juegos) comparte una única dirección IP pública asignada por su ISP. Internamente, su enrutador le da a cada dispositivo su propia IP privada (como 192.168.1.x).

Piense en ello como una empresa con un número de teléfono pero muchos empleados. Cuando alguien llama al número principal, la recepcionista necesita saber a qué extensión transferir la llamada.

El reenvío de puertos es la lista de reglas que le indican a su enrutador: "Cuando alguien de Internet se conecta al puerto 25565, transfiera esa conexión a la PC en 192.168.1.50".

Sin esa regla, el enrutador no tiene idea de dónde enviar la conexión entrante, por lo que la descarta.

Qué es un puerto

Cada conexión de red utiliza dos cosas: una dirección IP (qué computadora) y un número de puerto (qué aplicación en esa computadora).

Los puertos son solo números del 0 al 65535. Los más comunes que probablemente hayas visto:

Puerto Servicio
80 HTTP (web)
443 HTTPS (web segura)
22 SSH
25565 Minecraft Edición Java
3389 Escritorio remoto (RDP)
32400 Servidor de medios Plex

Cuando escribes google.com en su navegador, su computadora se conecta a la IP de Google en el puerto 443. Cuando su amigo intenta conectarse a su servidor de Minecraft, se conecta a su IP pública en el puerto 25565.

Sin un reenvío de puerto, su enrutador no sabe enviar ese tráfico de Minecraft a su PC para juegos en lugar de simplemente descartarlo.

Cuando realmente necesitas reenvío de puertos

Ejecutar un servidor al que se conectan personas fuera de su hogar.

Esta es la verdadera respuesta. Si aloja un servicio detrás del NAT IPv4 de su enrutador y desea conexiones entrantes directas, normalmente necesitará una asignación de puertos. Una retransmisión, un túnel de salida o una VPN superpuesta pueden proporcionar acceso sin un reenvío manual. IPv6 utiliza reglas de firewall en lugar de una asignación NAT de IPv4.

Casos específicos:

  • Servidor Java de Minecraft — puerto 25565, los amigos fuera de su red no pueden unirse sin él
  • Acceso remoto a Plex — puerto 32400, los clientes Plex externos no pueden acceder a su servidor sin él
  • SSH en el servidor de su hogar desde el trabajo — puerto 22 (o un puerto personalizado)
  • Escritorio remoto — comúnmente TCP 3389; Prefiero acceder a él a través de una VPN en lugar de exponerlo directamente.
  • Cámaras IP — utilice un método de acceso seguro compatible; Evite exponer su interfaz de administración directamente.
  • VPN autohospedada (WireGuard, OpenVPN) — requiere un reenvío de puerto en el puerto VPN

El hilo conductor: algo afuera su red está intentando iniciar una conexión en tu red.

Cuando no necesita reenvío de puertos

Esta es la parte que la mayoría de las guías se saltan.

Jugar juegos en línea como cliente no requiere reenvío de puertos. Te conectas a los servidores de EA, los servidores de Steam o PlayStation Network; esa es una conexión saliente que tu enrutador maneja automáticamente. No se necesita reenvío de puerto.

Los juegos y aplicaciones modernos utilizan técnicas transversales de NAT (STUN, ICE, perforación UDP) para establecer conexiones de igual a igual sin necesidad de abrir puertos manualmente. Cosas como:

  • Jugando Call of Duty, Fortnite, Rocket League
  • Usar el chat de voz de Discord
  • Videollamadas en Zoom, Teams, Google Meet
  • Transmisión en Netflix, YouTube, Twitch

Todos de salida. Todo funciona sin ningún reenvío de puerto.

¿Las guías de juegos que te dicen que abras varios puertos "para obtener un mejor tipo de NAT"? A veces es útil para plataformas muy específicas (Xbox, PlayStation clasificaciones de tipo NAT), pero rara vez es necesario para jugar juegos en línea.

UPnP maneja muchos casos automáticamente. Muchos enrutadores tienen habilitado Universal Plug and Play de forma predeterminada. Cuando una aplicación necesita que se abra un puerto, se lo pregunta directamente al enrutador y el enrutador lo abre automáticamente. Plex usa esto, muchos juegos lo usan. La desventaja es que es menos seguro: las aplicaciones pueden abrir puertos sin que usted lo sepa.

Cómo configurar el reenvío de puertos

La interfaz de usuario exacta difiere según la marca del enrutador, pero el proceso es el mismo en todas partes:

Paso 1: Dale a tu dispositivo una IP local estática

Los reenvíos de puertos apuntan a una dirección IP específica en su red local. Si la IP de su dispositivo cambia (las concesiones de DHCP caducan y se reasignan), el reenvío se interrumpe. Solucione esto mediante:

  • Configurar una IP estática en el propio dispositivo (en la configuración de red), o
  • Reservar una IP para la dirección MAC de ese dispositivo en la configuración DHCP de su enrutador

Paso 2: Encuentra el panel de administración de tu enrutador

Generalmente 192.168.1.1 o 192.168.0.1 en tu navegador. Consulte la etiqueta de su enrutador si no está seguro.

Paso 3: Busque la sección de reenvío de puertos

Busque: "Reenvío de puertos", "Servidor virtual", "NAT" o "Aplicaciones y juegos"; varía según la marca.

Paso 4: Crea la regla

Deberá completar:

  • Puerto externo (a veces llamado "Puerto de servicio" o "Puerto público"): el número de puerto por el que llega el tráfico entrante
  • IP interna: la IP local del dispositivo al que estás reenviando
  • Puerto interno (a veces llamado "puerto local"): normalmente es el mismo que el puerto externo, a menos que esté reasignando
  • Protocolo: TCP, UDP o ambos: consulte la documentación para saber qué necesita su aplicación

Paso 5: Guardar y probar

Guarde la regla. El reenvío de puertos se activa inmediatamente en la mayoría de los enrutadores.

Verificación de que su Port Forward realmente funcionó

Primero confirme que la aplicación se esté ejecutando y sea accesible dentro de su LAN. Luego usa el Comprobador de puertos con tu IP pública actual y puerto TCP externo. Mantenga el servicio en funcionamiento mientras realiza la prueba. Un verificador TCP no valida un servicio exclusivo de UDP, como un punto final WireGuard típico; Pruébelo con su cliente real.

Si la prueba falla, realice estas comprobaciones en orden. Detente cuando encuentres el primer paso fallido.

1. Confirme que el servicio esté escuchando localmente

Busque la dirección LAN actual del host y luego verifique el conector de escucha. Reemplace 25565 con el puerto TCP de su aplicación.

Windows PowerShell:

Comando 
Get-NetTCPConnection -State Listen -LocalPort 25565

Linux:

Comando 
sudo ss -lntp 'sport = :25565'

Un oyente obligado únicamente a 127.0.0.1 acepta conexiones locales, no conexiones ordinarias reenviadas a la dirección LAN del host. Configure la aplicación para escuchar en la interfaz LAN prevista según su documentación. Un oyente por sí solo no prueba que la aplicación esté funcionando correctamente.

2. Conéctese desde otro dispositivo LAN

Utilice el cliente de la aplicación para conectarse a la IP privada y al puerto interno actual del host. Para una prueba de TCP desde otra computadora con Windows:

Comando 
Test-NetConnection 192.168.1.50 -Port 25565

Sustituya la dirección y el puerto reales. Si falla el acceso a la LAN, arregle el servicio, el firewall del host o el aislamiento del segmento antes de cambiar el reenvío del enrutador. Permitir sólo el tráfico requerido; no desactive todo el firewall.

3. Haga coincidir todos los campos de la regla de reenvío

Confirme la IP de destino, el puerto externo, el puerto interno y el protocolo TCP/UDP. Prefiere una reserva DHCP para que el destino no se mueva. Si el puerto externo 30000 se asigna al puerto interno 25565, un cliente externo debe conectarse al 30000.

Para un destino desconocido, utilice nuestro flujo de trabajo de identificación de dispositivos para hacer coincidir la regla con la computadora correcta.

4. Verifique si hay una capa NAT ascendente

Compare la dirección WAN IPv4 del enrutador con su dirección IPv4 pública actual, usando la misma conexión a Internet sin VPN ni proxy. Una discrepancia sugiere una traducción ascendente o una ruta de tráfico diferente; lo hace no probar CGNAT por sí solo.

Una dirección WAN en 10.0.0.0/8, 172.16.0.0/12, o 192.168.0.0/16 es privado. Puede provenir de una puerta de enlace de un ISP que usted controle o de una NAT operada por un ISP. una dirección en 100.64.0.0/10 es un espacio de direcciones compartido que se utiliza a menudo para CGNAT; Confirme el acuerdo con su ISP.

  • Dos enrutadores que controlas: sigue las guía NAT doble.
  • NAT ascendente operada por el ISP: siga las Guía de verificación CGNAT y pregunta sobre una dirección pública u otro método de acceso admitido.
  • Coincidencia de WAN e IPv4 pública: continuar con pruebas externas; la coincidencia por sí sola no prueba que se permita el tráfico entrante.

5. Prueba desde una conexión realmente externa

Utilice un teléfono con datos móviles y Wi-Fi desactivado o el verificador TCP en línea. La prueba de su dirección pública desde su propia LAN puede fallar porque el enrutador no admite loopback. Si el acceso exterior funciona pero el acceso interior no, utilice el guía NAT de horquilla.

Verifique su IP pública nuevamente si se reinició la conexión. Si usa un nombre de dominio, compare su registro A con el IPv4 público actual usando Búsqueda de DNS. Verifique su registro AAAA por separado: una conexión IPv6 seguirá las reglas de enrutamiento y firewall de IPv6, no las de IPv4.

6. Interpretar el fallo en lugar de abrir más puertos

Resultado Lo que sugiere Siguiente verificación
La aplicación local falla Problema de configuración del servicio o aplicación Inicie el servicio y confirme su dirección de enlace
El local funciona, otro dispositivo LAN falla Firewall del host, aislamiento o destino incorrecto Verifique una regla de firewall estrecha y un segmento de red
La LAN funciona, se rechaza la prueba TCP externa Un endpoint o firewall rechazó activamente la conexión Confirmar destino, escucha, asignación y rechazar reglas
La LAN funciona, la prueba TCP externa se agota El tráfico o las respuestas pueden interrumpirse o desviarse incorrectamente Verifique la dirección WAN, NAT ascendente, reglas del enrutador y política del ISP
Trabajos externos, falla de LAN a IP pública Posible falta de loopback NAT Pruebe la dirección LAN o divida DNS
Se abre el puerto TCP, la aplicación aún falla La accesibilidad de TCP es solo una parte del servicio Verifique los registros de aplicaciones, TLS, autenticación y protocolos requeridos

Pregunte a su ISP sobre las restricciones de los puertos de entrada solo después de verificar el servicio local y la asignación del enrutador. Un tiempo de espera por sí solo no puede identificar qué firewall o red interrumpió el tráfico. Nuestro Guía de protocolo de enlace TCP explica la diferencia entre rechazo y silencio.

Unas palabras sobre seguridad

El reenvío de puertos expone un servicio de su dispositivo directamente a Internet. Ése es el punto, pero conlleva riesgos.

Algunas prácticas que vale la pena seguir:

No utilice puertos predeterminados para servicios confidenciales. La ejecución de SSH en el puerto 22 garantiza un flujo constante de intentos de inicio de sesión automatizados. Moverlo a un puerto no estándar puede reducir el ruido del escaneo de rutina, pero no es una medida de control de acceso y no impide el descubrimiento.

Utilice autenticación segura. Si está reenviando SSH o RDP, asegúrese de utilizar autenticación basada en claves o una contraseña segura, y considere incluir IP en la lista permitida si solo algunas ubicaciones necesitan acceso.

Audita tus forwards periódicamente. Mire la lista de reenvío de puertos de su enrutador de vez en cuando y elimine todo lo que ya no necesite. Los viejos delanteros que señalan dispositivos que ya no existen son solo una superficie de ataque.

Considere una VPN en su lugar. Si necesita acceso remoto general a su red doméstica (no solo a un servicio específico), configurar un servidor VPN WireGuard es más seguro que abrir varios puertos. Expones un puerto UDP y todo lo que hay detrás permanece protegido.

Conclusión

El reenvío de puertos es sencillo una vez que comprende la lógica subyacente. Su enrutador descarta todas las conexiones entrantes no solicitadas de forma predeterminada; el reenvío de puertos es su forma de decir "excepto esta".

Para el acceso IPv4 entrante directo detrás de NAT, verifique el servicio localmente, confirme la asignación y la ruta ascendente y luego realice una prueba externa. Para administración privada, considere una VPN o un túnel compatible.

Configúrelo, luego verificar que realmente funcione antes de pasar una hora depurando algo incorrecto. Y verifique si CGNAT es un problema incluso antes de comenzar: ninguna configuración del enrutador soluciona una IP pública faltante.

Referencias técnicas

El Especificación del espacio de direcciones compartido del IETF define 100.64.0.0/10. documentos de microsoft Obtener-NetTCPConnection y Prueba-NetConnection.