Barotrauma problems fall into two different groups: lag means the server and clients are exchanging data too slowly, while a failed join or timeout usually means the server cannot be reached. Start by checking whether another device can join on the same LAN, then test from an outside network. If the LAN test works, inspect NAT, port forwarding, firewalls and the ISP path. For a self-hosted dedicated server, verify the ports in serversettings.xml (the documented defaults are UDP 27015 for player traffic and UDP 27016 for queries), while in-game SteamP2P/EOS hosting can avoid manual forwarding in supported builds. The workflow below isolates each cause before you change hardware or report a game bug.
What is the difference between Barotrauma lag and a connection failure?
Lag is a session that connects but feels delayed: characters snap back, submarine systems respond late, or everyone sees rubber-banding. Valve describes latency as the time information takes to travel from your machine to the server and recommends checking latency and background bandwidth use in its Troubleshooting Lag guidance.
A connection failure happens before normal play: a friend cannot see the server, joining hangs at “connecting,” or the game reports a timeout. Those symptoms point first to reachability, firewall rules, NAT, port forwarding or an ISP route rather than to simulation speed.
| What players report | Most likely area | First check |
|---|---|---|
| Everyone moves in bursts or is pulled backward | Latency, packet loss, upload saturation or host load | Measure ping, packet loss, CPU, frame time and upload use during the spike |
| Only one player disconnects | That player’s route, Wi-Fi, firewall or local client | Have the player try another network and compare with a second client |
| New players cannot join, but current players remain connected | Reachability, NAT, firewall or a wrong forwarded port | Test from a phone hotspot or another external connection |
| Everyone times out immediately | Server not listening, blocked UDP port, incorrect address or ISP restriction | Confirm the running configuration and firewall before changing game settings |
Write down whether the trouble began after a game update, a mod change, a mission change or moving the host to another machine. That timing helps you choose the next test instead of treating every symptom as “lag.”
How should I classify the failure before changing anything?
Use the symptom pattern and scope of the failure to choose a test. Do not assume a high-end PC or a new router is required until you know whether the fault is local or on the internet path.
Everyone experiences delayed simulation
If all players see the same delay, inspect the host’s upload capacity, CPU and frame time, then check packet loss and other traffic on the connection. A saturated uplink can make a powerful computer appear to lag because state updates cannot leave the network promptly.
Only one person is affected
Ask that player to test without a VPN or powerline adapter, preferably on a different connection. If other players remain smooth, the shared server is less likely to be the cause; compare the affected player’s timestamps with the server log to look for a matching disconnect.
People cannot join at all
Start with reachability rather than graphics settings. Confirm that the host is running the intended mode, that the server is listening on the configured ports, and that the router and operating-system firewall send traffic to the correct machine.
How do I check game versions and mods?
Version and mod mismatches can prevent a clean connection or create desynchronization. The available documentation does not establish a percentage for how often they cause lag, so treat this as an isolation test rather than a statistical diagnosis.
- Have the host and every client record the exact game build shown by their launchers.
- Compare enabled mods, load order and any required workshop downloads. A server and client should use compatible versions and the same required content.
- Stop the server, disable all nonessential mods and start a new, unmodded session.
- Ask the same players to repeat the LAN and external tests. If the clean session works, re-enable mods in small groups until the failing set is identified.
Keep the original mod list and timestamps. They are useful evidence if the problem remains after the network path has been cleared.
How do I run a LAN test and an external test?
Testing in layers separates the game server from the internet path. A successful LAN join proves that one client can reach the host on the local network; it does not prove that friends on the internet can reach it.
- Use a second device on the same home network. Have another computer join the host by the game’s normal server browser or local address. Note whether it can enter a lobby and play for several minutes.
- Test outside the home network. Ask a friend to join, or connect a laptop or phone hotspot so the test uses a different ISP path. Do not rely solely on a client inside the same LAN, because some routers do not support reliable hairpin NAT.
- Compare the results. If LAN works but the external test fails, concentrate on router forwarding, NAT layers, firewall rules, ISP restrictions or a proxy. If both tests lag, measure the host and local uplink before changing forwarding.
- Repeat after each single change. Record the time, player, network used and result. Changing the router, mods and host machine at once removes the evidence needed to identify the cause.
Valve’s Troubleshooting Network Connectivity guidance likewise recommends checking local equipment, background applications and restrictions before assuming the game is defective.
How do I configure a Barotrauma dedicated server correctly?
The official dedicated-server guide says to set server options and port forwarding before starting DedicatedServer.exe. The documented defaults are UDP port 27015 for player traffic and UDP port 27016 for server queries. These are configuration values, not performance guarantees.
Verify the live XML values
- Open the current
serversettings.xmlused by the server installation. - Read the configured
portandqueryportvalues rather than assuming the defaults. - Use those exact numbers in the router and firewall rules.
- Start
DedicatedServer.exeand check its console or log for a successful bind and any address-in-use error.
The wiki’s Serversettings.xml reference warns that parts of the documentation can become outdated. Treat 27015 and 27016 as the documented defaults and confirm the values in your installed build after updates or configuration changes.
Allow the server through the operating-system firewall
In Windows Defender Firewall with Advanced Security, create inbound rules for the configured UDP player and query ports, or allow the Barotrauma server executable when prompted. Ensure the rule applies to the network profile the host is actually using. A rule for the wrong port, protocol or executable can look identical to a router failure from the player’s perspective.
Check Steam’s port guidance
Steam publishes a separate Required Ports for Steam reference. Use it to check whether a restrictive network, school or workplace firewall blocks Steam traffic in addition to the Barotrauma ports. Do not replace the game’s configured values with a list copied from another title.
How do I fix router, NAT and port-forwarding problems?
Forward the configured UDP ports to a stable local address for the host. A DHCP reservation is preferable to forwarding to an address that may change after a reboot.
- Reserve the host’s LAN address in the router’s DHCP settings.
- Create UDP forwarding entries for the server’s
portandqueryport(27015 and 27016 only when those are the current values). - Save the router configuration and restart the server so it binds to the intended interface.
- Retest from a phone hotspot or another external network. A test from inside the same LAN can succeed even when internet forwarding is broken.
When should I use UPnP?
UPnP can create mappings automatically where the router and game support it. The official wiki notes that UPnP can occasionally fail and is not universally supported, so manual forwarding remains the reliable fallback. If UPnP creates a stale or incorrect mapping, disable it, add explicit rules and retest.
How do I recognize double NAT?
If the home router’s internet-facing address is itself private, another modem or router is performing NAT upstream. Put the second device into bridge mode, forward through both layers, or use a hosting path that does not require inbound forwarding. Your ISP may also restrict inbound traffic; an external test and the router’s WAN address provide better evidence than repeated local joins.
How do I measure host load and bandwidth during a lag spike?
Measure while the problem is happening, not several hours later. Record CPU utilization, memory use, frame time, upload rate and packet loss alongside the exact time and player count.
- Stop cloud synchronization, torrents, large downloads and high-bitrate streams on the host and other household devices.
- Watch whether CPU or frame time rises at the same moment players report rubber-banding.
- Check the router’s upload graph; a full upstream queue can add latency even when download speed looks normal.
- Repeat with one player, then with the normal player count, to see whether the load scales with the session.
Valve specifically recommends examining background applications and router conditions when troubleshooting lag. A direct wired connection is a useful diagnostic when Wi-Fi or powerline networking may be intermittent. A Cat6 Ethernet cable can remove wireless variability during the test, but it cannot repair an ISP route, blocked port, overloaded host or software defect.
Which Barotrauma hosting mode should I use?
Choose the mode that removes your actual bottleneck. In-game hosting is simplest when forwarding is the obstacle; a dedicated process suits a machine that should run without the full game client; managed hosting trades some control for an external location and support.
| Hosting mode | Setup and reachability | Host overhead and control | When it fits |
|---|---|---|---|
| In-game SteamP2P/EOS host | The official announcement describes this path as avoiding manual port forwarding. Behavior can change with game updates, so confirm it in the current build. | The game client remains open and shares local CPU, memory and uplink with play. Server controls are tied to the in-game host. | Small groups that want the quickest setup and can accept the host leaving the session. |
| Self-hosted dedicated server | Normally requires configured UDP forwarding, firewall rules and a reachable network address. | Runs without the full game client and gives direct access to settings, logs and mods. The machine and home uplink remain your responsibility. | Longer sessions, automated restarts or a host that should not be playing on the same client. |
| Managed game-server host | Usually avoids home NAT and exposes a provider’s location and network policy; exact requirements vary by provider. | Control-panel quality, CPU allocation, slots, mod support, backups, DDoS policy, support response and refund terms vary. Current US pricing or quote basis is not established here. | Homes with saturated uplinks, difficult NAT, no always-on machine or a need for a geographically closer server. |
The current server source references Steamworks and EOS networking for the in-game path in GameServer.cs. The official announcement on easier hosting is available at Steam’s Barotrauma update notice. Because networking behavior can change between builds, confirm that your installed version offers the expected SteamP2P/EOS behavior after an update.
What should I compare before paying for managed hosting?
- Server location relative to the players and the resulting latency.
- CPU allocation, memory, player-slot limits and whether those limits are hard or adjustable.
- Mod installation, workshop access, configuration-file access and backup frequency.
- Firewall, NAT and DDoS/network policies, including what traffic is filtered.
- Control-panel quality, restart tools, log access and support response times.
- Current US price or quote basis, renewal terms and refund policy.
Do not buy a faster plan until a clean session and a wired diagnostic show that the home host or uplink is the limiting factor. A provider cannot correct a client-side mod mismatch or a player’s unstable Wi-Fi.
How do I fix a Barotrauma “connection timed out” error?
Work from the outside in: prove the server is running, prove the ports are configured, then prove an external packet can reach them.
- Confirm the host launched the intended server mode and that no second process is occupying the configured port.
- Check
serversettings.xmlfor the actual player and query ports. - Match those values in the operating-system firewall and router forwarding rules, using UDP.
- Verify the router forwards to the host’s reserved LAN address, not an old DHCP address.
- Test from a network that is not the host’s LAN. If the external test fails while LAN succeeds, keep investigating NAT, firewall and ISP restrictions.
- Try in-game SteamP2P/EOS hosting in a current build. If that works while the dedicated path does not, the problem is likely in manual reachability configuration rather than the game installation.
A timeout that appears only for one friend warrants a test from that friend’s alternate connection. A timeout for every outside player, paired with a successful LAN join, is strong evidence of an internet-path problem.
How do I fix rubber-banding and delayed movement?
Rubber-banding usually reflects latency, packet loss, an overloaded uplink or a host that cannot simulate and transmit state quickly enough. Use a controlled session to separate those causes.
- Connect the host by Ethernet for the test and stop competing uploads and downloads.
- Record CPU, memory, frame time, upload utilization and packet loss during a reported spike.
- Run a clean, unmodded mission with a small player count, then repeat at the normal count.
- Compare a player near the host geographically with one farther away. A difference between regions points toward route or distance effects rather than a universal server fault.
- Check the server log at the exact timestamp and preserve the corresponding client reports.
If rubber-banding remains with a clean session, idle background traffic and a wired host, compare another hosting mode before replacing hardware. If only one route or player shows loss, investigate that connection separately.
What evidence should I collect before reporting a bug?
A reproducible report saves time for both you and the developers. Include the environment and the result of each network-layer test.
- Game build and operating system.
- Host mode: in-game SteamP2P/EOS or dedicated process.
- Complete mod list and load order, plus whether a clean session was tested.
- Mission, server settings and player count.
- Local and external test results, including the network used for each.
- Timestamps with time zone, latency, packet loss, CPU, memory, frame time and upload utilization.
- Server and client logs covering the failure.
- Router model, NAT arrangement and whether UPnP or manual forwarding was used.
Reproduce the issue without mods before calling it a game defect. If the clean session fails in the same way, attach the logs and the exact steps; if it succeeds, identify the smallest mod or configuration change that brings the problem back.
Is a dedicated server worth using?
A dedicated server is worthwhile when you need an always-on process, lower local game-client overhead, direct log and configuration access, or a host that should not be the active player. It is not automatically a cure for lag: it still depends on a reachable UDP path, sufficient CPU and memory, and an uplink that can handle the session.
Use in-game hosting first when manual forwarding is the only obstacle and the current build’s SteamP2P/EOS path works for your group. Move to a dedicated process when the host needs persistent control or when running the full client competes with the server. Consider managed hosting only after measurements show that home hardware, NAT or the home ISP path is the limiting factor.
What should I do first?
Classify the symptom, test a second client on the LAN, then test from outside the LAN. A LAN success with an external failure directs you to ports, firewall, NAT or ISP routing; lag in both tests directs you to host load, upload saturation, packet loss and mods. Verify the live XML ports, use a wired diagnostic, remove background traffic, and preserve a clean-session log before escalating.
Frequently Asked Questions
Can I host Barotrauma without opening router ports?
Often, yes, when the current game build’s in-game SteamP2P/EOS hosting path works for your group. A dedicated server normally still needs inbound reachability, so a successful in-game session does not prove that your manual forwarding is correct.
How many players can my home server support?
There is no universal player number established by the available documentation. Measure CPU, frame time, upload use and packet loss at the player count you actually plan to run, because the result depends on the mission, mods, host hardware and network path.
Do mods have a known lag rate in Barotrauma?
No reliable percentage is published for how often mods cause lag. Disable them for a clean comparison, then re-enable small groups so you can identify a reproducible conflict instead of assuming every delay is network-related.
Will upgrading my internet plan fix a timeout?
It can help only when the existing uplink is saturated during play. A faster download tier will not correct a blocked UDP port, double NAT, an ISP restriction or a firewall rule, so complete the LAN-versus-external test before changing plans.