Your Soulmask world dies the moment the host closes their laptop.
That is the core problem with co-op hosting. One player’s PC carries the entire world, their RAM, their internet connection, and their power schedule.
When they disconnect, everyone loses access. When their connection spikes, everyone lags. When the game crashes mid-save, progress disappears with no clean recovery path.
A dedicated server fixes all three. The world runs on its own machine, 24/7, independent of any player’s setup. Tribes come and go. AI activity scales. The server stays live.
This guide covers everything you need to run a Soulmask dedicated server, including Windows, Linux, and Docker setups, the correct App IDs, port configuration, save management, and the specific failures that break most first installs.
This is a post-1.0 setup guide, updated for Soulmask’s April 2026 full release, Shifting Sands support, and current private-server behavior.
If you have already tried once and hit errors, the troubleshooting section covers the ones the official documentation misses.
Quick Answer: To set up a Soulmask dedicated server in 2026, install the server with SteamCMD, use app ID 3017310 for Windows or 3017300 for Linux, open UDP 8777 and UDP 27015, configure launch parameters, then edit GameXishu.json after the first startup. Use at least 16 GB RAM and back up WS/Saved before every update.
Soulmask 1.0 also makes map planning more important. Cloud Mist Forest uses Level01_Main, while Shifting Sands uses DLC_Level01_Main and requires the Shifting Sands DLC. Private servers that want cross-map travel need two linked server instances with unique ports and cluster settings.
Quick Reference:
Windows dedicated server app ID: 3017310
Linux dedicated server app ID: 3017300
Game port: 8777/UDP
Query/listing port: 27015/UDP
Telnet/Echo admin port: 18888/TCP
RCON port: 19000/TCP, optional
Gameplay settings file: WS/Saved/GameplaySettings/GameXishu.json
For baseline private-server behavior, compare your setup against the Soulmask private server documentation before changing ports, saves, or admin settings.
Dedicated server mode note: Survival Mode is the safe default for private dedicated servers. Tribe Mode and Warrior Mode are temporarily disabled for private servers and remain limited to single-player and co-op until developer support changes.
Soulmask runs its world simulation as a server process. When hosted as a dedicated server, that process becomes the single authority for saves, AI, and player connections. If networking, ports, memory, or storage are misconfigured, the server may run but remain unreachable or unstable.
Peer-hosted sessions
Dedicated servers
This separation is what enables persistence and stability.
When you start a Soulmask dedicated server, it:
Players connect to the server, not to another player. The server remains active even with zero players online.
Soulmask servers can be joined in two ways:
If a server runs but does not appear in the list, the most common causes are:
This behavior is common across Steam-distributed multiplayer games, although Soulmask server visibility still depends on the configured query port, firewall rules, and current server status.
A Soulmask server can be:
…and still be unreachable.
That usually means the server process is running, but incoming traffic never reaches it. This is why port configuration and firewall rules matter as much as the install commands.
Soulmask servers allocate most of their memory during startup.
At launch, the server loads:
This causes a temporary memory spike before usage stabilizes. If the system runs out of available memory at this stage, startup can fail or the server can terminate early.
In many cases, errors appear only in log files, not in the terminal output. This makes memory-related failures easy to miss if logs aren’t checked.
A Soulmask dedicated server needs enough RAM, CPU, storage, and open UDP ports to run persistent world simulation without connection or save failures.
These tiers reflect safe planning ranges for multiplayer survival servers, not official Soulmask player limits. Use them as safe starting points.
For public worlds or long-running tribes, a bare metal dedicated server is usually a better fit than shared hosting because CPU, RAM, storage, and network capacity are reserved for one environment.
Best for learning and casual play.
This tier works for small groups when player count, tribe size, and world activity stay modest. Servers with too little memory may start but fail under load or become unstable during restarts.
Best for shared worlds with regular uptime.
As worlds age, memory usage grows. More tribes and AI entities increase pressure even if player count stays the same. Storage speed starts to affect save and restart times.
Best for public or heavily modded environments.
This tier gives headroom. It helps reduce restart failures and peak-activity instability. These numbers reflect operational safety, not minimum launch requirements.
Soulmask servers allocate a large portion of their working memory early in the server lifecycle. This includes world state, simulation data, and runtime systems required before players connect.
If available memory is tight:
This is why memory-related issues often look like networking or install problems.
Soulmask servers write and read world state during saves, restarts, and updates. Slower disks increase:
SSD or NVMe storage can reduce these delays. This does not change gameplay logic, but it can improve operational reliability during maintenance and peak activity.
Soulmask can use multiple threads, but many server issues appear first as memory, storage, or networking limits before CPU saturation. CPU upgrades help when CPU usage is the observed bottleneck. They do not fix RAM exhaustion, blocked ports, bad launch parameters, or visibility issues.
Load grows from:
Player count alone is a poor sizing metric.
Low headroom often causes:
Crashes don’t always corrupt data, but abrupt termination during writes increases risk. Proper memory headroom and clean shutdowns reduce this risk.
If your Soulmask server starts but players cannot find or join it, the cause is often networking. Soulmask requires two reachable UDP ports for gameplay and query traffic by default. If either one is blocked or mismatched, the server may appear offline even when running.
Players join Soulmask servers in two ways:
Both methods require the server to be reachable from outside the host machine. A running server process alone is not enough.
Soulmask dedicated servers rely on two separate UDP ports per server instance for player traffic and server listing.
Default ports (unless changed in startup parameters):
If either port is unreachable, players may see connection or listing problems.
This is a common failure pattern:
Common causes include:
Direct IP may still work when listing does not.
You must forward ports if:
Port forwarding maps outside traffic to your server’s internal IP.
Typical setup:
Without this, outside players cannot reach the server.
Home hosting
Cloud or dedicated servers
On cloud servers, you must:
Opening one but not the other can cause a silent connection failure.
Soulmask player and query ports are UDP-based by default, while Telnet/Echo and RCON admin ports use TCP.
Best practice:
If UDP traffic cannot reach the server, it may not appear or accept player connections.
Soulmask supports remote administration features, including RCON-style access.
Key points:
Public Soulmask servers should also consider a DDoS protected dedicated server when open UDP ports, server visibility, and public player access are part of the setup.
If you enable RCON, also configure 19000/TCP and restrict it with a strong password and trusted IP rules.
Do not trust:
Always test:
If outside traffic reaches the server and players can join, the network path is working.
You can run a Soulmask dedicated server three ways. Pick based on your skill level, uptime needs, and how much control you want. The setup steps differ, but the core rules stay the same: correct app ID, open ports, clean shutdowns, valid configs, and reliable backups.
Best if you want the fastest path to a testable Soulmask dedicated server.
Choose Windows if:
Trade-off: higher memory overhead and more manual update/restart control.
Best for long-running, automated, and public Soulmask servers.
Choose Linux if:
Trade-off: steeper learning curve.
Best for controlled environments and repeatable builds.
Choose Docker if:
Trade-off: more setup steps and stricter port handling.
Move to RedSwitches gaming dedicated servers for dedicated resources, safer uptime, and stronger control over growing worlds.
Windows offers the easiest entry point for hosting and testing a Soulmask dedicated server. The setup relies on SteamCMD, a clean directory layout, and a repeatable startup script. Windows works well for testing and small servers but needs manual update, restart, and resource control for long-running use.
On Windows, Soulmask runs as a standalone server process.
You do not host through the game client.
The server files are downloaded and updated using SteamCMD, which is Valve’s command-line tool for server deployments.
This matters because:
SteamCMD handles:
Install it in a short, simple path, such as:
C:\SteamCMD
Avoid long paths, spaces, special characters, and protected folders such as Program Files. Windows path limits and permissions cause startup failures more often than bad commands.
SteamCMD downloads files using an App ID.
Use the current platform-specific Soulmask dedicated server app ID.
Current app IDs:
Windows dedicated server: 3017310
Linux dedicated server: 3017300
Recheck these IDs after major patches before updating a published guide.
Windows SteamCMD install command:
steamcmd.exe +login anonymous +force_install_dir C:\SoulmaskServer +app_update 3017310 validate +quit
Use 3017310 for Windows unless official Soulmask documentation changes. Linux uses a different dedicated server app ID: 3017300.
Keep tools and server files separate:
C:\SteamCMD → SteamCMD tool
C:\SoulmaskServer → Soulmask server files
This layout:
Do not move the server directory after installation. SteamCMD tracks file paths.
On Windows, you should always start the server through a startup script, not by clicking the executable.
A startup script:
This is usually a .bat file placed in the server directory.
Why this matters:
Soulmask generates configuration files after the first successful server launch.
The exact location depends on how the server is built and may be:
Best practice:
Start the server once, then confirm generated config paths from the server files or logs before editing.
Do not edit configuration files while the server is running.
Why:
Safe workflow:
This avoids unpredictable behavior.
Windows servers fail for repeatable reasons:
These issues are usually environmental, not Soulmask bugs.
Updates are manual by design.
Standard flow:
Do not update while the server is running. Always control shutdowns yourself.
Linux is the preferred platform for long-running Soulmask servers because it gives you tighter process control, predictable restarts, and lower baseline resource usage at the OS level. The setup takes more effort than Windows, but uptime and control improve.
Linux is built for server workloads.
This does not mean Linux never needs reboots. Kernel updates still require them. The difference is you control when, not the OS.
On Linux, you run Soulmask as a dedicated user process, not as root.
The typical model:
This keeps the system secure and predictable.
SteamCMD works the same way on Linux as on Windows:
Important rules:
Use app ID 3017300 for Linux unless official Soulmask documentation changes. Using the wrong app ID causes broken or incorrect installs.
Create a dedicated user for the server.
Why:
What to ensure:
Permission errors usually surface in logs or service output, not as silent failures.
You have multiple valid options.
Shell script
Service manager (systemd, OpenRC, runit)
systemd is common on modern distributions, but it is not mandatory. The correct choice depends on your distro and comfort level.
If your system uses systemd, it can:
You do not need advanced systemd knowledge. A basic service definition is enough. If your system does not use systemd, use the native service manager or a supervised script.
Best practice applies regardless of OS:
Why:
This is a general server rule, not a Linux or Soulmask-specific quirk.
Linux servers often block inbound traffic by default.
Before testing:
If ports are blocked, the server may run but remain unreachable.
Most Soulmask Linux setups target:
Package names and install steps vary by distro. Always follow distro-specific SteamCMD instructions rather than copying commands blindly.
Linux SteamCMD install command:
steamcmd +login anonymous \
+force_install_dir ~/soulmask-server \
+app_update 3017300 validate \
+quit
Use 3017300 for Linux unless official Soulmask documentation changes. Validate checks file integrity during updates. Do not move the install directory after deployment.
Docker can give you repeatable builds and clean restarts when ports, volumes, and memory limits are configured correctly.
It also adds networking, persistence, and memory layers that can make Soulmask unreachable or unstable if you map ports, volumes, or RAM limits incorrectly. Use Docker only if you understand container networking and persistence.
Docker standardizes the runtime environment.
This helps when you:
Docker does not change Soulmask’s game logic or performance model.
Soulmask Ports in Docker
Soulmask uses default ports that must be mapped explicitly unless you change them in launch parameters.
Common ports:
If gameplay or query ports are missing or mismatched, the server may run but remain unreachable. If admin ports are missing, remote admin access may fail.
On bare metal:
With Docker:
Traffic path:
All three layers must agree.
docker run -d \
-p 8777:8777/udp \
-p 27015:27015/udp \
-p 18888:18888/tcp \
-p 19000:19000/tcp \
your-soulmask-image
Rules:
Docker never opens firewalls for you.
Community Soulmask Docker images exist, but you should not assume they are official or that they share the same internal paths and ports.
Community images may:
You must always inspect:
Never assume internal ports, paths, or startup commands match another image.
Without volumes, you lose:
Example bind mount:
-v /opt/soulmask/data:/path/required/by/your/image
The correct volume path keeps world data and configs across restarts.
No persistent volume can mean fresh data after container rebuilds or removals.
Docker containers respect memory limits.
If Soulmask exceeds its limit:
Set memory explicitly:
–memory=16g
Or in Compose:
mem_limit: 16g
Do not under-allocate RAM.
Docker does not restart containers by default.
Use:
–restart unless-stopped
This:
Without this, a crash can leave the server offline until you restart it manually.
Most Docker issues are configuration mistakes.
Symptoms:
These are usually deployment mistakes, not Soulmask bugs.
Docker does not:
It controls how Soulmask is packaged and started, not the game’s core performance model or server rules.
Use Docker if:
Avoid Docker if:
Linux without Docker is usually simpler for first-time Soulmask server admins.
Before changing any values, you need to understand how Soulmask separates startup behavior, engine rules, and gameplay logic.
Soulmask uses three configuration layers. Each layer controls a different class of behavior. They are not interchangeable, and changing the wrong one often has no effect.
Purpose: Server identity and runtime behavior
Startup parameters are passed when you launch the server. They define how the server starts, not how the game plays.
Typical use cases:
Where they live:
Key rule:
These settings may override gameplay defaults, but only for values explicitly exposed as launch flags.
Purpose: engine-level behavior
Engine.ini controls supported Unreal Engine server-side settings used by Soulmask.
This may include supported networking or runtime behavior settings, but it should not be used for gameplay balance.
Typical location (generated after first run):
What belongs here:
What does NOT belong here:
Important safety note:
Do this before edits:
cp Engine.ini Engine.ini.backup
Restart required for all changes.
Purpose: gameplay rules and balance
This file controls how Soulmask actually plays.
Typical controls:
Location:
General pattern:
Location varies by host/build. Common path: WS/Saved/GameplaySettings/GameXishu.json. Search under WS/Saved/ or use your panel’s file manager path.
Critical rules:
Validate before restart:
jq . GameXishu.json
Always restart after GameXishu.json edits.
Do not rely on hot reload behavior unless official documentation confirms it.
These layers serve different purposes.
Some values may appear to overlap. When they do, explicit startup flags usually take priority, but only for that specific value. There is no global “override everything” rule.
Most “config not working” reports come from:
Here is how to update and maintain a Soulmask server while reducing save-loss and downtime risk.
Soulmask server files update through SteamCMD. SteamCMD updates server binaries and related files on disk.
What SteamCMD does not do:
You must take the server offline before updating.
If you want help with OS updates, monitoring, security hardening, and recovery workflows, managed dedicated server hosting can reduce the operational burden without removing your server control.
Always use a graceful shutdown.
Choose the method that matches how you run the server:
Do not use kill -9 unless the process is completely stuck. It skips cleanup and can interrupt save writes.
Soulmask stores world data under the server’s Saved directory.
Typical layout:
Soulmask-Server/
└── WS/
└── Saved/
├── SaveGames/
├── Config/
└── Logs/
This directory is what keeps your world alive.
Back up before every update.
Example:
tar -czf soulmask-backup-$(date +%Y%m%d-%H%M).tar.gz \
~/Soulmask-Server/WS/Saved/
Store backups off the server if possible.
Run SteamCMD only after the server is fully stopped.
steamcmd +login anonymous \
+force_install_dir ~/Soulmask-Server \
+app_update 3017300 validate \
+quit
What this does:
The validate flag checks file integrity and can repair missing or changed files.
Start the server the same way you normally do:
Do not rush the restart. First launch after an update may take longer.
After restart, verify all of the following:
Check logs:
~/Soulmask-Server/WS/Saved/Logs/
Use judgment, not autopilot.
If a major patch drops, consider waiting a short period to see if hotfixes follow.
Roll back using your backup.
tar -xzf soulmask-backup-YYYYMMDD-HHMM.tar.gz -C ~/
Then restart the server.
Do not rely on SteamCMD rollback unless the developer exposes an older branch.
Your own backups are the safest rollback path.
Let’s match each failure symptom to its real cause and fix it without guesswork.
| Symptom | Likely Cause | What to Check | Fix |
| Server not listed in browser | Query port blocked | UDP 27015 is not open | Open 27015/UDP on host + router + cloud firewall |
| Server not listed, but direct IP works | Query port blocked, game port open | Firewall rules | Open 27015/UDP specifically |
| Server not listed anywhere | Server still starting | Startup time + RAM usage | Wait until startup completes |
| Server works on LAN only | NAT not forwarding ports | Router port forwarding | Forward 8777/UDP and 27015/UDP for players; forward 18888/TCP only if Telnet/Echo admin access is required |
| Connection timeout | Game port blocked | UDP 8777 exposure | Open 8777/UDP |
| Connection timeout | Wrong IP or port | Connection format | Use <public_ip>:8777 |
| Direct IP fails | Server not listening | Port bind status | Verify ports are listening |
| Steam init fails on startup | Incomplete or broken update | File validation | Re-run SteamCMD with validate |
| Steam init fails repeatedly | Outdated server files | Server version | Update the server to match the client |
| Server exits during startup | Not enough RAM available | Memory at launch | Add RAM or close other services |
| Server crashes on startup | Other services consuming RAM | System memory | Free RAM before launch |
| Server starts, then exits (Linux) | Save or log path not writable | Directory permissions | Fix ownership of WS/Saved/ |
| The server appears online, players can’t join | Version mismatch | Client vs server version | Update server |
| Admin commands don’t work | Echo port blocked | TCP 18888 | Open 18888/TCP |
| World won’t load after a crash | Interrupted save | Save integrity | Restore from backup |
| Second server won’t start | Port conflict | Ports already in use | Assign unique ports |
| Docker server unreachable | Port mapping wrong | Docker -p flags | Map 8777/UDP, 27015/UDP, 18888/TCP, and optional 19000/TCP |
Check logs before guessing.
~/Soulmask-Server/WS/Saved/Logs/
└── WS.log
Useful checks:
# Steam-related issues
grep -i steam ~/Soulmask-Server/WS/Saved/Logs/WS.log
# Startup or crash errors
grep -i error ~/Soulmask-Server/WS/Saved/Logs/WS.log
# Check ports are listening
ss -u -lpn | grep -E ‘8777|27015’
ss -t -lpn | grep -E ‘18888|19000’
# Firewall status
sudo ufw status
sudo iptables -L -n
# Memory check
free -h
If ports are not listening, the server is not exposing them on the host.
If ports are listening but traffic fails externally, check OS firewalls, provider firewalls, NAT, security groups, and port mappings.
Startup crashes are usually not fixed by lowering player count.
Why:
Correct fix:
First startup after update can take 1–3 minutes, longer on HDDs. Do not assume failure until logs stop progressing.
Let’s focus on what actually keeps Soulmask servers stable over long uptime, not guesses or brute force.
Player count is one of the easiest load controls you have.
Each player increases:
Start conservative. Let the server run for hours. Increase caps only after confirming stable memory, CPU, storage, and network behavior.
Safe approach
Soulmask runs AI and world simulation continuously. You may not have direct controls for AI internals, but world activity still matters.
What increases load:
Practical guidance:
This can reduce server pressure without relying on unconfirmed hidden settings.
Some simulation behavior is engine-driven and not always exposed.
Do not assume:
If you experiment:
If you can’t confirm a setting exists, don’t rely on it.
Long-running servers often show gradual memory growth.
This does not always mean a memory leak.
Common causes:
What matters is the trend.
Monitor memory:
free -h
ps aux | grep WSServer
If memory usage climbs steadily and never drops, schedule low-traffic restarts and investigate logs.
Restarts can clear accumulated runtime state.
Recommended baseline:
Restart more often only if monitoring shows need. Restarts are maintenance, not failure.
Logs usually signal performance issues. Repeated high-volume logging can also add disk activity.
Watch for:
Log location:
WS/Saved/Logs/WS.log
Quick checks:
tail -n 50 WS.log
grep -i error WS.log
Repeated errors can signal instability or misconfiguration.
Save operations hit disk.
Warning signs:
Best practice:
If saves slow down, players may feel lag or delayed shutdowns.
Scale in this order:
Hardware helps most when load, configs, and network exposure are already controlled.
A stable Soulmask server:
Let’s secure access and protect your world so one bad moment doesn’t wipe months of progress.
Admin access equals full control.
Do this:
Avoid:
One leaked admin password can compromise the server.
Admin rights should be rare.
Best practice:
This follows least-privilege security. Fewer admins mean fewer mistakes.
Soulmask admin access is commonly controlled server-side through passwords or configured admin tools.
Common patterns:
If you run startup scripts or services, treat them as sensitive files.
Protect:
Back up state, not just saves.
Always include:
Why:
Also back up:
Backing up the full Saved/ directory avoids guesswork.
Minimum standard:
If players log in daily, back up daily.
Backups stored only on the same server are not enough.
Because:
Use:
Off-machine storage improves recovery odds.
Test restores on a spare server when possible.
Example cron job:
0 3 * * * /home/soulmask/backup.sh
Automated backups reduce missed-backup risk.
Protect the machine itself.
Do this:
Game security starts with server security.
Only expose what players need.
Guidelines:
Unnecessary open ports increase attack surface.
Once configuration is correct, remaining stability issues usually come from hardware, memory, storage, or network limits.
Under heavy load, servers may face memory pressure, CPU contention, save delays, or network jitter. At that stage, hardware and network quality often become the constraint.
RedSwitches supports high-performance Soulmask servers by reducing the resource limits that commonly cause instability.
With dedicated server hostingF, you can size CPU, RAM, NVMe storage, and bandwidth around your actual player count, map plan, and backup schedule.
Our dedicated and bare-metal servers provide reserved hardware resources, reducing resource contention compared with shared hosting. This helps reduce slowdown, crash, and forced-restart risk when the server is correctly configured.
We also deliver consistent CPU performance. Dedicated cores reduce noisy-neighbor risk and provide more predictable performance than shared virtualized environments.
Combined with high-bandwidth, low-latency networking, this supports smoother connections and more reliable UDP traffic during combat and large events.
With global server locations, you can deploy closer to your players to reduce latency.
The result is a Soulmask server environment designed for better stability, cleaner scaling, and more predictable performance, so you spend less time fighting hardware limits.
Q. What is the Soulmask dedicated server app ID?
Use app ID 3017310 for the Windows dedicated server and 3017300 for the Linux dedicated server. Recheck official sources after major patches before publishing or updating setup commands.
Q. What ports does a Soulmask dedicated server use?
Soulmask uses 8777/UDP for game traffic and 27015/UDP for query/listing by default. Telnet/Echo admin access uses 18888/TCP, and RCON can use 19000/TCP when enabled.
Q. Where is GameXishu.json in Soulmask?
GameXishu.json is commonly located at WS/Saved/GameplaySettings/GameXishu.json after the first successful server run. Stop the server before editing it.
Q. How many players can a Soulmask dedicated server handle?
A 16 GB server is a practical starting point for small groups. Stable player count depends on world size, tribe activity, AI behavior, settings, storage, memory, and uptime. Always scale after observing memory, CPU, storage, network behavior, and logs.
Q. Why does my Soulmask server not show up?
A common cause is blocked UDP ports. Soulmask requires 8777/UDP (game) and 27015/UDP (query). If direct IP works but listing does not, check 27015/UDP, server filters, version match, and listing delay.
Q. Is Linux better than Windows for Soulmask?
Usually, yes, for long-running servers. Linux usually uses less idle memory and offers cleaner process control, though kernel and security updates may still require planned reboots. Windows works but needs more headroom and controlled update/restart settings.
Q. Can I run Soulmask in Docker?
Yes. Docker can work well for repeatable setups when ports, volumes, and memory limits are configured correctly. You must map UDP gameplay/query ports, map TCP admin ports only when needed, and persist saves with volumes. Incorrect port mapping is a common failure point.
Q. How often should I restart my server?
For public or long-running servers, schedule restarts during low-activity periods only when monitoring shows memory growth, save delays, or repeated log warnings. This can help stabilize memory use and reduce degradation when the server shows a repeatable issue pattern.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。