Respuesta directa: si el puerto 25565 no funciona en tu servidor Minecraft, no abras reglas al azar. Comprueba de dentro hacia fuera: proceso y escucha, server.properties, firewall del sistema, publicación en Docker o allocation de Pterodactyl, firewall del proveedor, DNS y, solo en casa, NAT o CGNAT. Corrige la primera capa que falle y repite la prueba.
Minecraft Java usa TCP 25565 por defecto; Minecraft Bedrock usa UDP 19132 por defecto. Son rutas distintas: abre únicamente la correspondiente a la edición que alojas. Las referencias oficiales explican la configuración de un servidor Java y la conexión a un servidor Bedrock. Esta guía documenta comandos para Ubuntu 24.04 y Debian 12/13; no afirma haberlos ejecutado en tu VPS.
Empieza por el síntoma, no por el firewall
| Síntoma | Qué demuestra | Primera capa que revisar |
|---|---|---|
| Connection refused | La ruta llegó a un host que rechazó la conexión. | Proceso detenido, escucha en otra IP/puerto, mapping ausente o rechazo explícito. |
| Connection timed out | No hubo respuesta antes del límite. | UFW, firewall del proveedor, DNS/AAAA, NAT, CGNAT o ruta de retorno. |
| Incompatible version, Outdated client/server | El cliente ya habló con una aplicación Minecraft. | Versiones, proxy, mods o compatibilidad; el puerto no es el problema principal. |
| Not whitelisted o error de autenticación | La red y el protocolo llegaron al servidor. | Whitelist, cuenta, online-mode o autenticación del proxy. No abras más puertos. |
El texto exacto cambia según cliente, versión y proxy. Usa también el log del intento: un mensaje de versión o whitelist es evidencia de que varias capas de red ya funcionan.
Prerrequisitos y punto de restauración
- Ubuntu 24.04 o Debian 12/13, acceso
sudoy una ventana para reiniciar solo el servicio del juego. - La IP pública, el puerto anunciado y la edición reales. No confundas IP pública, privada, de contenedor o de allocation.
- La ruta y unidad reales del servidor. Aquí se usan
/srv/minecraftyminecraft.servicecomo ejemplos. - Acceso a la consola o logs y una segunda conexión a Internet para la prueba externa.
Antes de editar, copia server.properties. Cambia la ruta si tu instalación usa otra:
cd /srv/minecraft
sudo cp -a server.properties "server.properties.before-25565-$(date +%Y%m%d-%H%M%S)"
sudo grep -E '^(server-ip|server-port)=' server.properties
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.
sudo ss -lntp 'sport = :25565'
sudo ss -lnup 'sport = :19132'
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:
server-ip=
server-port=25565
Edita el archivo con sudoedit. Si ya confirmaste que systemd gestiona esa instancia, reinicia únicamente su unidad y lee el inicio completo:
sudoedit /srv/minecraft/server.properties
sudo systemctl restart minecraft.service
sudo systemctl --no-pager --full status minecraft.service
sudo journalctl -u minecraft.service --since '15 minutes ago' --no-pager
sudo ss -lntp 'sport = :25565'
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:
nc -vz PUBLIC_IP 25565
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:
sudo ufw status verbose
sudo ufw status numbered
sudo ufw allow 25565/tcp comment 'Minecraft Java'
sudo ufw status numbered
Aloja tu servidor Minecraft
Explora opciones de hosting para tu servidor Minecraft y elige el entorno que mejor encaje con tu comunidad.
Si alojas Bedrock en vez de Java, usa esta regla, no la anterior:
sudo ufw status verbose
sudo ufw status numbered
sudo ufw allow 19132/udp comment 'Minecraft Bedrock'
sudo ufw status numbered
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.
docker ps --format 'table {{.Names}}\t{{.Ports}}'
docker port CONTAINER
docker inspect --format '{{json .NetworkSettings.Ports}}' CONTAINER
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:
services:
minecraft:
ports:
- '25565:25565/tcp'
Para un servidor Bedrock, utiliza en cambio:
services:
bedrock:
ports:
- '19132:19132/udp'
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
sh
dig +short A play.example.net
dig +short AAAA play.example.net
dig +short SRV _minecraft._tcp.play.example.net
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:
sudo tcpdump -ni any 'tcp port 25565'
sudo tcpdump -ni any 'udp port 19132'
- 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
ssy 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
ssmuestra el proceso y protocolo correctos en la dirección esperada.- El log registra un arranque limpio y el intento externo.
- El firewall efectivo para esa ruta —incluida la ruta Docker—, el firewall del proveedor y el mapping/allocation exponen solo el puerto necesario.
- A y AAAA apuntan a rutas funcionales; SRV, si existe, corresponde a Java y a un hostname válido.
- 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.
