Puerto 25565 no funciona: diagnostica tu servidor Minecraft paso a paso

1. Confirma qué proceso escucha

Para Java, inspecciona TCP. Para Bedrock, ejecuta solo la rama UDP. ss debe mostrar una escucha en el puerto esperado y, con sudo, el proceso asociado.

Una salida vacía significa que el firewall todavía no es el primer problema: revisa arranque y logs. Una escucha limitada a 127.0.0.1 no acepta tráfico público. Si otro PID ocupa el puerto, identifícalo antes de detener nada; no mates procesos desconocidos.

2. Revisa server.properties y reinicia de forma controlada

En Java, deja server-ip= vacío salvo que necesites enlazar una dirección local concreta y sepas que existe en el host. Confirma además el puerto:

Edita el archivo con sudoedit. Si ya confirmaste que systemd gestiona esa instancia, reinicia únicamente su unidad y lee el inicio completo:

En Pterodactyl, usa Stop/Start y la consola del servidor; no intentes gestionar el proceso del contenedor con esa unidad de ejemplo. Un error Address already in use, una excepción de Java o un cierre durante el arranque se resuelve en la aplicación, no agregando reglas.

3. Separa la prueba local de la externa

ss y el log de arranque son la comprobación local inicial. En Java, prueba después la IP pública desde otro dispositivo y otra red —por ejemplo, datos móviles—; nc -vz se usa aquí solo para TCP y debe ejecutarse desde esa red externa:

Un resultado TCP exitoso no valida versión, whitelist ni login de Minecraft. Para Bedrock/UDP, un escáner puede informar open|filtered o no recibir respuesta aunque la ruta exista. Verifica con un cliente Bedrock externo mientras observas logs y, si sigue ambiguo, captura paquetes como se explica al final.

4. Inspecciona UFW antes de permitir nada

Ubuntu documenta UFW como interfaz de firewall sobre Netfilter. Examina primero el estado y añade una sola regla para tu edición; no deshabilites el firewall como solución permanente. Para Java:

Si alojas Bedrock en vez de Java, usa esta regla, no la anterior:

Verifica de nuevo desde fuera. Si la regla fue el único cambio y debes revertirla, elimina exactamente la variante creada: sudo ufw delete allow 25565/tcp o sudo ufw delete allow 19132/udp, y vuelve a ejecutar sudo ufw status numbered. No borres una regla preexistente compartida.

sudo nft list ruleset es útil como diagnóstico de bajo nivel. No añadas reglas nativas de nftables si UFW administra el host: la documentación de Ubuntu sobre nftables advierte que mezclar ambos métodos puede producir interacciones inesperadas. Consulta también el resumen oficial del firewall de Ubuntu.

5. Comprueba el firewall del proveedor y la IP pública

Una regla local no modifica el firewall de la nube. En el panel del VPS o security group, confirma una entrada para TCP 25565 en Java o UDP 19132 en Bedrock, con el destino/instancia y la IP pública correctos. Revisa también balanceadores o NAT del proveedor. Evita abrir rangos o puertos administrativos para “probar”. Guarda el estado anterior y, si la prueba falla, revierte solo la regla nueva.

6. Sigue la rama de Docker o Pterodactyl

Docker

Comprueba el mapping efectivo; un EXPOSE en la imagen solo documenta el puerto y no lo publica. Docker requiere -p o ports:, como explica su guía de publicación de puertos.

Importante: Docker puede desviar el tráfico de puertos publicados antes de las reglas de UFW. No uses ufw status como prueba de que un puerto de contenedor está filtrado: considera la publicación accesible en todas las direcciones del host, verifica el resultado desde fuera y aplica la restricción en el firewall del proveedor o mediante una política compatible con Docker —por ejemplo, una cadena DOCKER-USER diseñada y probada—. No desactives a ciegas la gestión de firewall de Docker. Consulta la advertencia oficial sobre Docker y UFW.

Para un servidor Java, el fragmento de Compose es:

Para un servidor Bedrock, utiliza en cambio:

Aplica el cambio con el procedimiento normal de tu despliegue, recrea solo el servicio afectado y vuelve a comprobar docker port. No reinicies todo Docker a ciegas: interrumpirías otros contenedores sin demostrar la causa.

Pterodactyl

Una allocation es la combinación de IP y puerto asignada al servidor según la documentación de Wings. Comprueba que la allocation primaria y el puerto de la aplicación coincidan, y que su protocolo/ruta exterior estén permitidos. Una regla UFW no crea una allocation. No uses red de host como atajo. Si necesitas revisar el nodo, consulta la guía para instalar Pterodactyl Panel y Wings.

7. Verifica A, AAAA y SRV

El registro A debe devolver la IPv4 pública correcta. Si existe AAAA, el servidor, listener y firewalls deben aceptar esa IPv6; un AAAA roto puede hacer que algunos clientes fallen aunque IPv4 funcione. No lo elimines a ciegas: prueba ambos caminos y corrige la ruta IPv6 o cambia el registro de forma intencional.

Usa _minecraft._tcp solo para Minecraft Java en un puerto personalizado. El target SRV debe ser un hostname canónico con A/AAAA, no una IP ni un CNAME/alias; confirma además que el campo port devuelto sea el puerto público que usarán los clientes; el formato y ese requisito se definen en RFC 2782. Bedrock no se arregla con el SRV de Java. Para profundizar, revisa cómo funciona DNS.

8. Si alojas desde casa, comprueba NAT y CGNAT

Configura un reenvío al IP LAN fijo del servidor: TCP 25565 para Java o UDP 19132 para Bedrock. El protocolo debe coincidir y la regla debe traducir el puerto público que usan los clientes al puerto interno donde realmente escucha el servidor. Los números externo e interno pueden ser distintos; si lo son, anuncia el externo al cliente y verifica el interno con ss. Este comportamiento de traducción se describe en RFC 4787. Prueba desde fuera; algunos routers no soportan NAT loopback y una prueba desde la misma Wi-Fi puede engañar.

Compara la dirección WAN del router con tu IPv4 pública. Si la WAN cae en 100.64.0.0/10 —espacio compartido reservado por RFC 6598— o no coincide con la pública, puede haber CGNAT o doble NAT. Pide al ISP una IPv4 pública/port forwarding, corrige el segundo NAT o usa hosting/VPS. No existe una regla en el router doméstico que atraviese por sí sola el CGNAT del operador.

9. Usa tcpdump como decisión final

Inicia una captura breve en el host mientras alguien intenta entrar desde otra red. Escoge solo el filtro de tu edición:

• No llegan paquetes: tras confirmar filtro e interfaz, investiga antes del host: DNS, IP pública, firewall del proveedor, NAT, CGNAT o allocation.
• Llega SYN y vuelve RST/RST-ACK: la ruta alcanza el host, pero no hay listener TCP en esa dirección/puerto o una regla rechaza activamente; correlaciona con ss y el log.
• Llegan SYN repetidos y no sale respuesta: busca descarte en firewall local, ruta de retorno, firewall del proveedor o NAT. No atribuyas el silencio por sí solo a un listener ausente.
• Hay handshake TCP y luego desconexión: la ruta funciona; correlaciona hora y origen con logs de versión, proxy, autenticación, whitelist o aplicación.
• Llega UDP pero no hay respuesta: valida listener Bedrock, mapping, logs y reglas de retorno; un escaneo UDP aislado no decide el caso.

La diferencia entre un reset y las retransmisiones sin respuesta se deriva del comportamiento TCP descrito en RFC 9293.

La captura confirma metadatos y secuencia, pero el cifrado y el protocolo limitan cuánto contenido puedes interpretar. Detén tcpdump tras reproducir el fallo y evita conservar datos innecesarios.

Verificación final, rollback y mantenimiento

1. ss muestra el proceso y protocolo correctos en la dirección esperada.
2. El log registra un arranque limpio y el intento externo.
3. El firewall efectivo para esa ruta —incluida la ruta Docker—, el firewall del proveedor y el mapping/allocation exponen solo el puerto necesario.
4. A y AAAA apuntan a rutas funcionales; SRV, si existe, corresponde a Java y a un hostname válido.
5. Un cliente real entra desde otra red. Después valida versión, whitelist y juego normal.

Si el cambio empeora el servicio, restaura la copia exacta de server.properties, revierte el mapping o allocation, elimina solo las reglas local y externa que añadiste y reinicia de forma controlada. Documenta IP, puerto, protocolo, hora y resultado de cada prueba. Mantén sistema y servidor actualizados, restringe RCON/panel/SSH por separado y revisa reglas obsoletas; nunca dejes el firewall desactivado.

Si Java conecta pero Bedrock no, sigue la guía de GeyserMC y Floodgate. Si los jugadores entran pero hay tirones, el siguiente problema ya es rendimiento: diagnostícalo con spark, no tocando el puerto.