Antes de empezar
Anota Java o Bedrock, versiones de cliente y servidor, dirección con puerto y hora exacta. Conserva los mensajes de consola y los cambios recientes. Antes de modificar mundos, mods o archivos, prepara una copia que puedas restaurar.
Comprobar edición y dirección
Java y Bedrock no son intercambiables: Java utiliza normalmente TCP y Bedrock UDP. Un cliente Bedrock no accede sin más a un servidor Java cambiando el puerto. Usa la dirección asignada en el panel, comprueba el destino de la configuración DNS o SRV y evita confundir un acceso administrativo con el puerto del juego.
El juego Java generalmente usa un punto final TCP, mientras que el juego del servidor Bedrock usa UDP. Los valores predeterminados comunes nunca reemplazan la asignación del panel. En un nodo compartido, copiar un puerto predeterminado de un tutorial puede entrar en conflicto con otra instancia. Una prueba TCP no puede validar la conectividad de Bedrock UDP.
Prueba solo la conexión TCP de Java desde Windows
Test-NetConnection -ComputerName 192.0.2.10 -Port 25565Sustituye dirección y puerto por los asignados al servicio. TcpTestSucceeded=True solo confirma el establecimiento de TCP; no comprueba UDP de Bedrock, la autenticación de Minecraft ni el rendimiento. Si aparece False, compara la escucha, el arranque y las reglas de ese puerto concreto.
Verificar el arranque completo
El proceso puede estar activo mientras todavía carga el mundo. Revisa que el arranque haya finalizado y busca errores de Java, configuración, plugins o mods. Si reinicia continuamente, diagnostica primero ese ciclo. Encadenar reinicios rápidos aumenta la carga y puede ocultar el mensaje que explica el fallo; guarda los registros antes de cambiar varias cosas.
Después de agregar un complemento o mod, verifique sus dependencias y compatibilidad del motor. Paper, Fabric, Forge y NeoForge no cargan automáticamente las mismas extensiones. Utilice una copia de prueba y elimine únicamente la adición identificada; Eliminar un mundo no es una forma de diagnosticar un error de software.
Probar el protocolo adecuado
Comprueba la correspondencia autorizada entre IP pública y puerto. Un test TCP no valida un puerto Bedrock UDP. La visibilidad LAN de Bedrock puede abrir además los puertos estándar aunque hayas configurado otros; en un nodo compartido debe ajustarse al esquema del operador. No abras puertos adicionales ni de otras instancias para intentar resolverlo.
Luego compare desde otra conexión autorizada. Cuando solo falla una red, registre su proveedor y los tiempos en lugar de cambiar inmediatamente la configuración global. El ping ICMP bloqueado no establece que el juego sea inaccesible; una respuesta de ping tampoco prueba que el puerto del juego esté abierto.
Comprueba el DNS de Java sin cambiar la zona
dig +short A play.example.com
dig +short SRV _minecraft._tcp.play.example.comUn registro SRV de Java puede anunciar otro destino y puerto. Resuelve también el nombre devuelto y compáralo con la asignación. No hace falta SRV si el cliente ya usa la dirección y el puerto correctos. Esta prueba no comprueba UDP de Bedrock.
Contrastar versiones y dependencias
Compara versión de juego, software del servidor y loader. Un modpack puede necesitar la misma combinación de mods en cliente y servidor. Si el problema empieza tras un cambio, revisa esa dependencia con una copia previa. Un downgrade o un cambio de mundo puede hacer incompatibles los datos; no borres el estado original para probarlo.
Bedrock El descubrimiento de LAN también puede abrir sus puertos habituales además de un puerto personalizado. En un nodo compartido, utilice la configuración adaptada del panel y solicite una verificación de conflicto de asignación. Para un proxy Java o una puerta de enlace de juego cruzado, inspeccione cada etapa de la ruta en lugar de solo la dirección pública.
Medir la carga durante el fallo
Observa CPU, memoria y consola en el momento del problema. Un hilo principal saturado puede bloquear Minecraft aunque la media de la máquina sea baja. En Paper, perfila la situación con spark cuando ocurra. Comprueba las distancias de vista y simulación y posibles sobrescrituras en otras configuraciones: añadir RAM no corrige necesariamente esa carga.
Cuando sea compatible, perfile el servidor durante el problema con una herramienta compatible. Las versiones recientes de Paper incluyen spark. Un informe de un servidor vacío es menos útil que uno capturado durante la desaceleración. Enlaza la grabación y protege los enlaces de diagnóstico que puedan contener información confidencial.
Preparar un diagnóstico reproducible
Compara otro acceso a Internet y determina qué jugadores fallan. Guarda hora, endpoint y mensajes pertinentes, eliminando credenciales y datos privados. Un timeout puede venir de ruta, filtrado, protocolo incorrecto o servidor no preparado. Atribúyelo a un ataque o a falta de recursos solo cuando las medidas de red y aplicación lo respalden.
La actividad sospechada de DDoS necesita correlación con mediciones de tráfico o eventos de mitigación. Un tiempo de espera por sí solo no es prueba suficiente. Evite reinicios repetidos y exploraciones agresivas: añaden carga y dificultan el diagnóstico. Pruebe la solución utilizando una conexión normal y luego verifique que los jugadores habituales puedan regresar.
Qué hacer en tu caso
| Situación | Próximo paso |
|---|---|
| Edición incorrecta | Selecciona Java o Bedrock y su endpoint real. Cambiar el puerto no convierte una edición en otra. |
| Fallo tras cambiar mods o mundo | Contrasta versiones y dependencias, conservando una copia separada del estado anterior. |
| Solo falla bajo carga | Perfila el hilo principal y los chunks durante el problema antes de elegir un plan mayor. |
Fuentes oficiales
Estas fuentes explican los protocolos y ajustes mencionados. Comprueba siempre la documentación de tu versión.