¿El comprobador de puertos dice abierto? Por qué los jugadores de Minecraft siguen sin poder entrar

Alguien ejecuta una comprobación de puerto, ve la palabra abierto y da el servidor por resuelto. Lo que ese resultado significa en realidad es estrecho: desde la ubicación del comprobador, en ese momento, se aceptó una conexión TCP a esa dirección y ese puerto. No dice nada sobre el protocolo de enlace de Minecraft, la autenticación de la cuenta ni si el servidor admitió al jugador en un mundo.

Son cuatro capas diferentes, y un fallo en cualquiera de ellas produce la misma frase del jugador: no funcionó.

Una sonda solo prueba lo que puede ver

Una conexión TCP se completa cuando ambos lados terminan el protocolo de enlace de tres vías, que está por debajo de todo lo que el juego sabe. La sonda informa de que existía un oyente y respondió desde su ubicación de red. No puede decirte que el oyente sea el juego, porque cualquier proceso puede ocupar un puerto y aceptar conexiones.

La ubicación importa tanto como el resultado. Un comprobador en la internet pública prueba una ruta desde una red. Un comprobador que el operador ejecuta desde dentro de la misma red prueba una ruta completamente distinta, y un resultado positivo allí no dice casi nada sobre lo que experimenta un jugador remoto. Dos comprobadores distintos en dos proveedores distintos pueden incluso no coincidir por razones que no tienen nada que ver con tu servidor.

El momento también importa. El resultado de una sonda describe el instante en que se ejecutó, y una conexión doméstica con dirección dinámica o una regla de reenvío cambiada puede mover la respuesta real unos minutos después. Anota la dirección pública, el puerto, la familia de direcciones y la hora junto con el veredicto, o la observación no es reproducible. Repite la comprobación desde una red genuinamente distinta y no desde un teléfono en la misma conexión.

Cuatro capas entre un socket y un jugador

Imagina la secuencia que realiza realmente un cliente que se une. Primero resuelve la dirección, luego abre una conexión TCP al puerto publicado, luego habla el protocolo propio del juego para negociar y autenticar, y por último el servidor decide si esa identidad puede entrar en el mundo. Cada capa tiene su propia firma de fallo, y solo la primera es visible para un comprobador de puertos.

El puerto predeterminado de Java Edition es 25565, pero el operador puede publicar un puerto externo distinto y reenviarlo hacia dentro, así que el número que escribe un jugador no es necesariamente el número que ve el servidor. Un comprobador dirigido al puerto externo equivocado informa cerrado mientras el servidor está perfectamente sano, y esa es la falsa alarma más común en todo este ámbito.

Los nombres añaden un paso más por encima del puerto. Si un jugador escribe un nombre de host, la resolución debe devolver la dirección publicada, y en una máquina dentro de la red puede devolver una privada en su lugar. Eso no es un fallo del cortafuegos y ninguna cantidad de redirección de puertos lo cambiará.

Por qué el jugador de dentro toma una ruta distinta

Un jugador en la misma LAN, o en una VPN que llega a esa LAN, intenta alcanzar la dirección pública desde dentro. La petición va a la dirección externa del router y el router tiene que traducirla de vuelta hacia dentro, que es la disposición que suele llamarse hairpinning o reflexión de NAT. Tanto la traducción de ida como la ruta de vuelta tienen que encajar para que funcione, y muchos routers domésticos no lo implementan en absoluto.

Por eso el invitado de fuera se une y la persona sentada junto al servidor no puede. La ruta externa está genuinamente bien; el desvío interno es lo que falla, y falla de una forma que desde la pantalla del jugador parece un problema del servidor. El propio registro del servidor resuelve cuál de los dos ocurrió, porque una conexión que nunca se tradujo nunca llega a él.

Hay dos arreglos honestos y una mala costumbre. Las buenas opciones son dejar que los jugadores internos usen la dirección privada o un nombre de split-DNS que resuelva internamente a la dirección privada, o habilitar la reflexión en el router si la función existe y se comporta bien. La mala costumbre es abrir más puertos o desactivar el cortafuegos del host, lo que no puede afectar a una traducción que el router nunca realizó.

La documentación de Netgate sobre la reflexión de NAT describe con más detalle la distinción entre externo e interno y la alternativa split-DNS. Léela como una descripción del mecanismo y no como una promesa de que cualquier proveedor de VPN o router concreto admita todas las variantes de loopback.

Recoge pruebas desde cada punto de vista

Para cada prueba, anota quién la ejecutó, desde dónde, a qué hora, contra qué dirección y puerto, y qué registró el servidor. Un rechazo del juego con un motivo claro en la consola del servidor es un hallazgo distinto de una conexión que nunca llegó, y los dos llevan en direcciones opuestas.

Si los jugadores remotos permitidos se unen y un jugador local no puede, la ruta local es la pregunta que queda y merece su propia investigación: qué dirección usó el cliente, qué hizo el router con la traducción y si el servidor registró algún intento de conexión. Entrega esos tres hechos a quien posea la red en lugar de reabrir puertos al azar.