Find your next check
Choose the last step that failed and change one thing at a time Save important data before changing files A green status or open port alone does not prove that a player can join
| What happened | Check next | How to confirm |
|---|---|---|
| The server stops during startup | Read the first specific error in Console and Diagnosis Check the selected Java for that server version or the missing game executable Bedrock and Palworld do not use Java | The ready message appears and a compatible client joins locally |
| The host can join but another LAN device cannot | Use the host's private IPv4 and configured game port Check client edition and version and the allowlist Allow only the required app or game port through the firewall | A second device joins on the same network before you test Internet access |
| LAN works but an external friend cannot join | Check forwarding destination and protocol Java normally uses TCP Bedrock and Palworld use game UDP Check CGNAT and whether the relay supports this game Never expose Palworld REST | A friend on another network joins in-game An open-port test alone is not enough |
| An extension change causes errors | Save a backup and stop the server Check game and loader versions dependencies and client requirements Test only the last change in a separate copy | The test copy starts and a compatible client joins Keep the original backup until verified |
| A restored world looks wrong | Stop without making more changes Check the backup's server date version and contents Do not overwrite or delete the preserved current world | Known buildings and inventory match in-game and both recovery copies remain available |
| Palworld safe stop reports a save error | Check local REST is enabled and the configured management port and credentials are correct Keep REST private Do not treat a forced kill as a successful save | The save request succeeds and the server exits without a save error Then verify the world on the next start |
1. Installation and Windows warnings
Download from the GitHub Release linked on this site and compare the package name and SHA-256 with its published checksums. The Tauri update signature and Windows Authenticode are different mechanisms. The published package is not Authenticode-signed. Do not bypass an unfamiliar warning just because a guide says to do so. If the source or hash differs, stop and contact us before installing.
2. The server does not start
For Java version errors, select Java compatible with the exact server version rather than changing Windows PATH. For EULA errors, read and accept the terms yourself. For a missing JAR or executable, check whether creation or download completed; do not substitute files from an unknown mirror. For a port-in-use error, stop the conflicting server or choose an unused port. Palworld uses native binaries; installing Java does not fix a missing PalServer.exe.
3. Friends cannot connect
Check in order: server ready → host client → second device on LAN → external friend. Use the host's private IPv4 only within the LAN. Confirm client edition and version and the allowlist. Java normally uses TCP; Bedrock and Palworld game traffic uses UDP. Forward the configured port and protocol, not a remembered default. If LAN succeeds but Internet fails, check the forwarding destination, CGNAT and relay support. Never expose a REST management port or disable all firewall protection.
4. Mods fail or the server lags
Check the first dependency or loader error and the project's server/client requirements. Record the last extension changed and test a backed-up copy with that change removed. Do not repeatedly add random fixes. During lag, compare CPU, RAM and disk activity with the time of the symptom. Reduce view or simulation distance gradually and observe again. More allocated RAM is not always the solution and can leave too little for Windows. A diagnosis is not a performance guarantee.
5. Restore without losing the current world
Save and safely stop first. Confirm no server process is writing to the folder. Preserve the current world and configuration before selecting a dated backup for the same server. Check archive integrity when the app offers it. After restoration, start the server and join in-game to verify known builds, inventory and settings. Keep both copies until verified. If Palworld world-save fails, do not treat a forced kill as a successful safe stop. Never test recovery by deleting the only original world.
6. What to send to support
Send your TomoNode version, game/server type, client version, the steps you took and the shortest relevant error after redaction. Say whether the host and LAN tests worked. Remove IP addresses, player names, chat, email addresses, passwords, tokens and local paths from screenshots or excerpts. Do not send a world or entire log by default. Response times are not guaranteed.
Before restoring a backup
- Save and safely stop Confirm the server process is no longer writing
- Preserve the current world and settings separately Keep a copy on another disk when possible
- Select the backup for the same server Check its date version ZIP and SHA-256 integrity If validation fails stop instead of forcing restoration
- After restoration start and join in-game Check known buildings inventory and settings Keep both copies until this check succeeds
A minimal support report
Copy these labels into an email yourself This page sends nothing Remove IP addresses player names chat passwords tokens email addresses and local paths from any error excerpt Do not attach complete logs or a world by default
TomoNode version: Windows version: Game / server type / game version: Client edition / version: Steps to reproduce: Expected result / actual result: Host test / LAN test / external test: First specific error with private data removed: Last setting or extension changed: