7 Days to Die Console Crossplay Server Cannot Join

Freeze the working PC state

1. 1Stop changing ports, world names, and gameplay values while crossplay is being isolated.
2. 2Copy the active server XML, current save, matching GeneratedWorlds directory, serveradmin.xml, Mods directory, and recent logs to a dated folder.
3. 3Record the server build/branch and one PC join result so a later test cannot be mistaken for the original failure.

Audit every current crossplay gate

• Server and clients use the current matching Stable build.
• ServerAllowCrossplay is true and EACEnabled is true in the active XML.
• EOS sanctions are not ignored.
• The player maximum is eight or fewer.
• No third-party/non-bundled mods are loaded.
• World and gameplay values remain within the current console-compatible restrictions.

Confirm the server is reading the XML you edited

A correct property in an unused serverconfig.xml changes nothing. Read the actual -configfile launch argument, resolve it from the process working directory, and check the startup log for the server name and settings expected from that file.

1. 1Stop the process cleanly before editing XML.
2. 2Check for duplicate property names, invalid quotes, or an old owner-named file still referenced by the service.
3. 3Restart once and save the new startup log before testing a console client.

Separate compatibility from outside reachability

If no outside client can join, solve TCP 26900 and UDP 26900-26903, Windows Firewall, router forwarding, double NAT, or CGNAT first. If PC WAN joining works but only consoles fail, return to the crossplay gates rather than broadening firewall rules or deleting data.

Safe resolution

Create a copied, mod-free console profile if the production PC world depends on mods or incompatible values. Do not remove data-bearing mods from the only world and save over their missing objects. Keep distinct PC-modded and console-compatible identities when both experiences are needed.

Interpret the console test instead of treating every failure alike

A successful PC join proves that the process reached a playable world and that at least one PC network route works; it does not prove that EOS advertisement, EAC state, or the console rules are correct. A console that never discovers the server points toward advertisement, platform eligibility, or outside-network reachability. A console that reaches the server and is then rejected is stronger evidence of a build, EAC/EOS, player-cap, setting, or mod compatibility gate.

Keep a small evidence table with the server build, client platform/build, discovery result, join result, and the first relevant log line. Repeat the same test after changing only one gate. That record prevents a router change from receiving credit for a profile correction and gives The Fun Pimps' current requirements—not guesswork—a clear place in the diagnosis.

Follow the branch that matches the console outcome

When neither PlayStation nor Xbox can discover the listing, first prove that the server completed startup with crossplay enabled and then run one test from a different internet connection. If PC direct joining also fails from that outside connection, the shared failure belongs to the public network path rather than a console-only rule. If outside PC joining succeeds, preserve those network settings and inspect EOS advertisement, the active XML, and every eligibility gate before changing forwarding.

When the server is visible but the join is refused, capture the exact client message and the corresponding server-log window. Compare the reported client/server builds, EAC state, sanctions policy, player cap, and loaded mod list. If one console family succeeds and the other fails from equivalent outside networks, repeat with a second account and second console before changing the server; platform service, account, or local-console state is then a credible branch that a server rebuild cannot prove.

• Discovery absent everywhere: verify completed startup, active crossplay configuration, advertisement, and the public route.
• Discovery present but join rejected: preserve the route and inspect build, EAC/EOS, player limit, settings, and mods.
• LAN succeeds while every WAN test fails: map the address path, including double NAT or CGNAT, before editing gameplay XML.
• Only one console/account fails: reproduce on another matching client before declaring the dedicated server incompatible.

Stop before a test can damage the working world

Stop the crossplay experiment if meeting the console profile would require removing a data-bearing mod from the only save, changing the world selector, or starting the production save under an unverified build. Clone the full identity and create a separate console-compatible profile instead. Also stop broad network changes when the same public PC test remains successful; that result is evidence that the established route should be held constant.

Do not publish a server merely because it appears in search. A release-ready result requires one successful PC join and one successful join from each intended console family, all from outside the host LAN, followed by a clean save and shutdown. Restart the same identity and repeat discovery and joining without changing any value. Record builds, platforms, account type, XML checksum, mod-free status, public test method, and first/second-start results as the acceptance matrix for the next update.

Prevent the next crossplay regression

Keep the verified console XML as a versioned profile separate from a PC-modded profile. Before a stable update, archive the active XML, save, generated map, permissions, logs, and a redacted launch record. After the update, compare The Fun Pimps' live requirement page, validate the copied profile privately, and promote it only after the same platform matrix passes. This turns a future console complaint into a controlled comparison against a known configuration instead of another round of simultaneous port, mod, and world changes.