Windrose Can't Host or Join, Kicked to Menu: Invite and Party-Join Fixes (2026)

Windrose Can't Host or Join, Kicked to Menu: Invite and Party-Join Fixes (2026)

Updated June 2026.

One of the most common Windrose connection complaints is a deceptively simple one: you try to host or join, the game thinks for a moment, and then either throws a vague error, shows "failed to join party," or drops you back to the menu. As of June 2026, that symptom is still one of the clearest player-facing problem clusters around the Early Access window. It matters because Windrose does not use the classic "type an IP and port" pattern that many survival players expect. The official join flow is invite-code based, the game is currently designed to use IPv4 only, and the connection model leans on a NAT-traversal handshake over UDP/TCP port 3478 with the developer's backend at windrose.support rather than a single fixed public-port workflow. That means a surprising number of failures look like mysterious in-game problems when the real blocker is a missing tutorial completion, DNS filtering, an IPv6-preferring system, a first-launch firewall miss, a VPN or proxy layer, or an ISP that quietly blocks the NAT-traversal port.

There is also a second category that feels similar from the player's perspective: the game is not truly blocked by the network, but the world or host state is bad enough that Windrose cannot complete the join handoff. The result still looks like "host failed" or "join failed," but the fix is different. The job of troubleshooting is to separate those buckets quickly. If you do that, the problem usually becomes much smaller than it first appears.

This guide walks the highest-probability causes first: the client-side tutorial gate, build matching, DNS and IPv6, firewall and the port 3478 NAT path, VPN and proxy layers, the invite code itself, and finally world-state isolation. For the closely related "failed to join party" disconnect pattern see Windrose failed to join party, and if a dedicated server shows no code at all see Windrose server not showing or no invite code.

Why this issue is so common in Windrose

What recent community reports are actually pointing to

A recurring Windrose discussion thread about being unable to host a game or join a friend contains several especially useful data points. One player traced the failure to DNS filtering that blocked windrose.support, reporting that NextDNS had blocked the domain and that allowing it restored connectivity. Another player confirmed that the game also reaches connection-service infrastructure and concluded "it is 100% DNS or firewall if you have some region blocking on it." A third got a temporary fix only after forcing the game's firewall prompt to appear properly on Windows by disabling the firewall, hosting once, and re-enabling it so the allow rule was created cleanly. That last detail shows the initial permission handoff can fail silently on some systems.

The official Windrose FAQ adds the network detail behind those reports: the game is currently designed to use IPv4, certain ISPs block the backend services required to connect, and the developers ask affected players to have their ISP allowlist the windrose.support domain and the NAT-traversal port 3478 (UDP and TCP). The FAQ also confirms that VPN and proxy layers should be disabled while testing. Put differently: this is not just "the servers are bad." In many cases the game is being blocked locally, by your DNS resolver, by an IPv6 preference, or by your ISP, before the actual co-op path can come alive.

That does not mean every failed join is DNS or firewall. It means those checks are high-value because they match both the current design and real player fixes. The single biggest exception is the tutorial gate below, which produces a silent failure that no amount of network tuning will fix. Start with the highest-probability blockers first.

Best troubleshooting order

1. Confirm every player has finished the singleplayer tutorial; multiplayer is gated behind it and fails silently if it is not complete.
2. Make sure everyone is on the same Windrose build and has fully restarted Steam.
3. Check DNS filtering, ad-block DNS, region-blocking filters, or strict family-safe DNS rules, and test with a plain public resolver such as 8.8.8.8 / 8.8.4.4.
4. Rule out IPv6: the game is currently designed for IPv4, so force IPv4 preference if your network leans IPv6.
5. Force Windows to show or refresh the firewall permission prompt for both Steam and Windrose on the correct network profile.
6. Turn off VPN or proxy software for the test.
7. Confirm the NAT-traversal path is open: UDP and TCP port 3478 reachable, and ask your ISP to allowlist windrose.support if it blocks backend services.
8. Retry with one fresh host and one guest only, using the exact current 8-character, case-sensitive invite code.
9. If the issue persists, test with a fresh world to separate network failure from world-state failure.

Step 1: Rule out the silent tutorial gate

This is the single most overlooked cause of a "join failed" or silent kick in Windrose, and it has nothing to do with your network. Windrose requires every player to finish the singleplayer tutorial before they can join any multiplayer session. If a brand-new account that has never completed the tutorial enters a perfectly valid invite code, the join is rejected without an error popup, without a message, and without anything in the client UI explaining why. Server-side and player-side everything looks normal, which is exactly what makes this so misleading.

The gate is enforced on the client, so a server operator cannot turn it off. It affects dedicated servers, friend-hosted sessions, and co-op games equally. If you have a new player who cannot join while everyone else can, check this before touching DNS or firewalls.

The fix is simple: boot a singleplayer world, play through the opening tutorial sequence until the game marks it as complete, then return to the invite code. Most players report this takes roughly 15 to 30 minutes. For the full breakdown of this specific symptom see Windrose tutorial required for multiplayer.

Step 2: Confirm you are testing a valid build pairing

The Windrose dedicated-server guidance is explicit that the game version and dedicated-server version should match. That matters even if you are not operating a public rented server, because self-hosted and friend-hosted sessions still depend on a clean handshake between current client state and current session state. Right after a hotfix, the game can appear to be the same product to the player while actually being mismatched underneath. When that happens, a join attempt may fail in a way that looks like connectivity.

Before anything else, have every player fully exit Steam, relaunch it, verify the game updated, and then relaunch Windrose. If one person stayed on an older process after the hotfix, the whole debugging session turns into noise. For the dedicated-server side of this problem see client and server version mismatch after a Steam update.

Step 3: Check whether DNS filtering is the actual blocker

The strongest concrete community fix we have for the menu-fallback problem is DNS-related. In the existing host/join error thread, one player reported that windrose.support had been blocked by NextDNS, and allowing it immediately restored connectivity. Another player said regional blocking broke the same flow. That does not prove every failed join uses that same domain path, but it is enough to treat DNS as a first-line check, not an edge case.

Here is the practical version of that advice:

• If you use NextDNS, Pi-hole, AdGuard DNS, Quad9 with strict filters, or a security suite with domain blocking, temporarily relax it for a test and add windrose.support to the allowlist.
• If you use region blocking or custom deny lists, disable them long enough to retry the join.
• If your router or security software rewrites DNS requests, test with a plain public resolver for one session: manually set your IPv4 DNS to Google Public DNS (8.8.8.8 and 8.8.4.4) or Cloudflare (1.1.1.1) instead of automatic assignment.

You do not need to permanently abandon your preferred DNS setup. You only need one clean test to answer the question: is Windrose being blocked before it can complete the session handshake?

Step 4: Force IPv4 if your system prefers IPv6

The official FAQ states Windrose is currently designed to use IPv4. Modern Windows installs and many home networks prefer IPv6 when both are available, and that preference alone can break a connection that should otherwise succeed. The symptom is identical to a network block: you reach Steam, Discord voice, and ordinary websites fine, but the Windrose join keeps failing or dropping you back to menu.

To rule this out, force IPv4 preference for one test. On Windows this is done with a registry adjustment to the IPv6 prefix policy (the FAQ describes the supported approach), after which you reboot and retry the join. If the connection then works, you have isolated the layer; if it does not, move on rather than leaving an unusual network configuration in place. This is also worth checking on routers that aggressively advertise IPv6 to every device.

Step 5: Re-trigger Windows firewall permissions

Another useful launch-era report described a situation where temporarily disabling firewall protection let the game create the proper allow rule the next time it ran. That points to a subtle but familiar Windows problem: the first launch permission prompt either never appeared, was dismissed, or was granted only on the wrong network profile. If that happens, Windrose may fail in an unhelpful way instead of telling you "Windows blocked this."

The disciplined way to test this is:

1. Close Windrose fully.
2. Open Windows Defender Firewall, choose "Allow an app through firewall," and confirm both Steam and the Windrose executable are present.
3. Make sure both the Private and Public checkboxes are ticked for each, and remove obviously stale or duplicate rules from failed first runs.
4. If the entries are missing, use "Allow another app" and browse to your Windrose installation to add it.
5. Launch Windrose again, watch for the permission prompt, and allow it on the network profile you are actually using.
6. Retry the host or join flow immediately after that clean launch.

If you are not confident editing firewall rules, keep the test simple: momentarily lower the barrier just long enough to see whether Windrose succeeds once. If it does, stop digging at the game layer and add Windrose back as a proper exception rather than leaving the firewall off.

Step 6: Remove VPN and proxy variables

The official FAQ says to disable proxy or VPN software temporarily when connections fail. That is good advice because Windrose is not merely opening a public socket and waiting. Its current join model depends on service-mediated connectivity and a NAT-traversal handshake that VPNs often disrupt. Even when they do not break it fully, they can change the path enough to produce inconsistent "it worked twice, then failed again" behavior. Those intermittent cases are especially misleading because they tempt you to blame the world save or the game code.

If you use a VPN all the time, do one clean test without it. If the problem disappears, you have your answer. Keep the rest of the session boring until you know which layer is at fault.

Step 7: Check port 3478 and the ISP-block path

Windrose's co-op connection relies on a NAT-traversal handshake (STUN/TURN style) over UDP and TCP port 3478 with the developer's backend at windrose.support. Some ISPs with aggressive "security" filtering quietly block that traffic while leaving Steam, Discord voice, and ordinary web browsing fully working. The result is a player who can do everything online except complete a Windrose connection. The official advice for this case is to contact your ISP and ask them to allowlist the domain and port.

If you suspect this, two tests narrow it down quickly:

• Try connecting from a completely different network, such as a phone hotspot. If the join succeeds there, your home ISP or router is the blocker.
• Try a network layer that bypasses ISP-level filtering for one session, then retry the join.

When you contact your ISP, give them concrete details rather than "my game does not work." A clear request reads: domains *.windrose.support, port 3478, protocols UDP and TCP, traffic type STUN/TURN for NAT traversal, purpose legitimate game connectivity. The deeper version of this scenario, including which carriers have shown the pattern, is covered in Windrose ISP blocks, DNS, IPv6 and port 3478.

Step 8: Treat the invite code as the truth source on dedicated servers

If you are troubleshooting a true dedicated server rather than a player-hosted co-op world, stop guessing and inspect the actual invite code path. The code you should see is an 8-character, case-sensitive string, and you should either find it in the console after boot or inside the server's metadata file under its data tree. If there is no current invite code there, the server is not ready. If the invite code exists but players are typing an older one, the connection will fail even though the service looks alive from the outside.

Because the code is 8 characters and case-sensitive, a single mistyped letter from a stale screenshot or a copied Discord note can easily create a fake "network issue." A lowercase letter and its uppercase form are different characters, so confirm the casing exactly. Always read the current code directly from the server, not from memory. For the full generation and reading workflow see the Windrose dedicated server invite-code guide.

There is also one documented quirk worth knowing: two PCs on the same local network may be unable to connect to each other using an invite code. If your whole crew is on the same home network, that is expected behavior, not a fault. The supported workaround is a direct connection using the host machine's local IP address instead of the code. For players across different networks, the host can also forward a chosen game-server port for both TCP and UDP and have guests use a direct connection.

Dedicated server join sanity check:
1. Server starts cleanly
2. Current 8-character invite code appears
3. One updated client (tutorial complete) joins
4. Then the wider crew retries

Step 9: Use a fresh world to separate world trouble from network trouble

If the tutorial, DNS, firewall, and VPN checks all look clean, create a controlled test. Have the host try a fresh world or a minimally touched world. If that clean world works but the original world does not, the problem is no longer a generic network failure. It is likely tied to save state, host state, or version-specific world data. That distinction saves hours.

Players often skip this step because they do not want to think their main world is risky. That is understandable, but the test world is not there to replace the real one. It is there to answer one question cleanly: does Windrose fail on every session or only on this specific session?

Step 10: Do not confuse player-hosted and dedicated workflows

Windrose supports both self-hosted and dedicated sessions, but they are not operationally identical. A friend-hosted world depends on the host's client, the host's local network, and the host's permissions. A dedicated world depends on the dedicated-server package, its metadata files, and the dedicated runtime. When users mix those models in one troubleshooting conversation, the results are chaotic. The fix for a broken dedicated server may have nothing to do with the fix for a player-hosted world that gets kicked back to menu.

Decide which model you are debugging before you touch anything else:

• Player-hosted world: focus on tutorial completion, client build, firewall, DNS, IPv4 preference, VPN, and whether the host can open a fresh local world.
• Dedicated server: focus on invite code generation, the server metadata file, world binding, and build matching.

If you are deciding which model to run in the first place, the trade-offs are laid out in self-hosted vs dedicated Windrose servers.

What not to do

• Do not start tuning the network for a brand-new player before confirming they finished the singleplayer tutorial.
• Do not jump straight to manual port forwarding unless you have already checked the tutorial gate, DNS, IPv4 preference, firewall, and VPN behavior.
• Do not keep retrying the same broken host state with four people at once.
• Do not trust an old invite code after a rebuild or restart, and remember the code is 8 characters and case-sensitive.
• Do not assume "the server process is running" means the join path is healthy.
• Do not mix local-world and dedicated-world troubleshooting steps unless you know which mode failed.

When the problem is probably upstream, not yours

If the player has finished the tutorial, you have tested with current builds, disabled VPN and DNS filtering, forced IPv4, confirmed the firewall prompt and port 3478 path, and even a fresh world still fails in the same vague way, it becomes reasonable to suspect an upstream bug rather than your setup. That is especially likely shortly after a hotfix, when active Steam topics cluster around loading and connectivity complaints. At that point, stop making random changes, preserve your working notes, and wait for the next hotfix or troubleshooting update rather than wrecking a previously stable machine configuration. You can track current server-side health on the Windrose dedicated server status page.

Source

The networking facts above (invite-code join flow, IPv4-only design, port 3478 NAT traversal, the windrose.support backend and ISP allowlist guidance, and the VPN and firewall advice) are confirmed in the official Windrose FAQ: playwindrose.com FAQ.