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 real
El código de salida lo imprime tu lanzador o tu panel de alojamiento, no el juego. La causa está en logs/latest.log y, en caso de fallo, en el informe que el servidor guarda en crash-reports/. Lee hacia atrás desde el final del registro 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 | El watchdog mató un tick bloqueado, la JVM se negó a arrancar, o un lanzador o cargador de mods informó de un fallo |
| 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 dedicado de Bedrock es un programa distinto con su propio registro, y los consejos escritos para registros de Java no se aplican a él.
Los entornos con mods fallan de otra manera
Con mods, la primera excepción suele ser un síntoma. Un mixin que no se aplica produce una cascada en la que el verdadero culpable es la primera línea de Mixin apply failed, no la de NoSuchMethodError treinta líneas después. 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 consulta de estado al puerto del servidor responde a eso en una sola petición. La herramienta de aquí comprueba servidores de Java; Bedrock habla UDP y necesita su propia consulta.
Pega el registro en la herramienta Server Diagnostics para que te extraiga la línea del fallo, y apúntala a tu host para confirmar que el servidor responde de verdad.