El código de salida no es un motivo de fallo, es un encogimiento de hombros
El número no te dice nada. La línea que está justo encima te lo dice todo, y ya está en tu carpeta de registros.
Un servidor de Java que muere imprime Exit Code 1 y se detiene. Ese es todo el mensaje. El código de salida 1 significa "el proceso terminó de forma anómala": es una categoría, no una causa, y abarca desde una carpeta de mundo que falta hasta un mod que lanza una excepción durante la carga de clases.
Dónde está la respuesta de verdad
El código de salida es la última línea de logs/latest.log. La causa está en las líneas anteriores. Lee hacia atrás desde el final hasta que encuentres el primer Exception, Caused by: o Failed to. Esa línea nombra la clase, el mod o el archivo.
[Server thread/ERROR]: Encountered an unexpected exception
java.lang.NoSuchMethodError: net.minecraft.world.level.Level.getBiome
at com.example.mod.ExampleMixin.inject(ExampleMixin.java:41)
Caused by: java.lang.NoClassDefFoundError: com/example/lib/HelperNoClassDefFoundError aquí es una dependencia que falta, no un mundo corrupto. El código de salida no te dijo nada de eso.
Códigos de salida que verás de verdad
| Código | Significado habitual |
|---|---|
| 0 | Apagado limpio — /stop o un reinicio programado |
| 1 | Excepción no controlada, o la JVM se negó a arrancar |
| 137 | El sistema operativo lo mató, casi siempre el OOM killer |
| 143 | SIGTERM — un orquestador de contenedores lo detuvo |
El código 137 es el que la gente malinterpreta como un fallo. La JVM no falló; algo externo a ella decidió que el proceso había usado demasiada memoria.
Java y Bedrock no son el mismo problema
El servidor de Bedrock escribe bedrock_server.log y no emite ningún código de salida al estilo de Java: vuelca un informe del gestor de fallos con una traza de pila y una línea Crash report. Los consejos escritos para registros de Java no sirven para él.
Los stacks con mods fallan de otra manera
Con mods, la primera excepción suele ser un síntoma. Un mixin que no se aplica genera una cascada en la que el verdadero culpable es la primera línea Mixin apply failed, no la NoSuchMethodError treinta líneas más abajo. Busca Mixin en el registro antes de buscar Exception.
Comprobar si el servidor está activo
Un registro te dice por qué murió. No te dice si sigue vivo ahora. Una comprobación TCP contra el puerto del servidor responde a eso en una sola petición, y funciona igual para Java y Bedrock porque ambos hablan a través de un socket.
Pega el registro en la herramienta de Diagnóstico de servidor para que te extraiga la línea del fallo, y apúntala a tu host para confirmar que el servidor responde de verdad.