Hytale Update 6 Part 13 Hotfix 1: Joining Friends Now Uses ICE, STUN and TURN (August 22, 2026)

On August 22, 2026, a section headed "Pre-Release (Update 6, Part 13, Hotfix 1)" appeared on Hytale's pre-release patch notes page. It is short. It is also the most consequential thing to happen to Hytale multiplayer since the pre-release run began, because it takes the single most common reason two people cannot play together and removes it. The headline entry, quoted exactly as written: "Play together, no matter your network! Joining friends no longer requires external apps!" "Players who couldn't join friends because of their NAT type can now connect without tools like Tailscale." If you have ever typed "hytale can't join friend" into a search box, you already know the answer that came back. It was install Tailscale. Every guide said it, this site's own guide said it, and, as of 25 August 2026, Hytale's own official support article still says it. That era ended on August 22, five days before Update 6 goes stable on Thursday August 27, 2026. One thing to settle immediately, because the headline invites the wrong conclusion: Tailscale is not dead for everyone. Two groups of players still cannot connect after this change — people on "Double NAT" setups, and people on networks that block UDP relay traffic — and for them a VPN overlay like Tailscale remains exactly as relevant as it was last week. The workaround has gone from being the standard answer to being a fallback for a minority. That is a large, real improvement, and it is not the same thing as "you never need it again". This article covers what actually changed, and — more usefully — the three boundaries the celebratory headline does not mention. All of them matter, and one of them will be misread by almost every server owner who skims this. We will get to that one first. Read This Before Anything Else: This Is Player-Hosted, Not Dedicated Servers The official wording is precise, and the precision is the whole point: "Player-hosted joins now use ICE (RFC 8445) with STUN and TURN, replacing the legacy hole-punch path." Player-hosted joins. That is the path where one player opens their own world and a friend joins it — the share-code flow, the "let me host, you connect" flow, the thing that breaks when somebody's router is uncooperative. That is what this change is about. It is not a statement about dedicated servers. Nothing in Hotfix 1 says a dedicated Hytale server stops needing a reachable address, an open port and a sane firewall. If you run a box — rented, colocated, or the spare machine under your desk — the networking work you did to make it reachable is exactly as necessary on August 28 as it was on August 21. Hotfix 1 does not touch it, does not replace it, and does not make port forwarding optional for you. We are labouring this because the failure mode is predictable: a server owner reads "joining friends no longer requires external apps", concludes Hytale now punches through everything, tears down a working setup, and spends launch weekend rebuilding it. If you run a dedicated server, our Hytale server hosting requirements and setup guide, our self-hosted versus managed hosting comparison and our server setup guide all describe a world Hotfix 1 leaves untouched — the port-forwarding and NAT advice in them stands. So does our explainer on native transfers versus proxies. What Actually Changed: ICE Replaces the Hole-Punch Path Three technical lines carry the entire change. Here they are in full, because the exact wording is doing work in each one: "Player-hosted joins now use ICE (RFC 8445) with STUN and TURN, replacing the legacy hole-punch path." "TURN relays carry joins when no direct path works. The relay uses UDP only, so networks that block UDP relay traffic cannot use it." "Failed ICE attempts fall back to the existing direct connection race." And the player-facing summary of what the relay is for: "When no direct connection is possible, the join is carried over a relay server." For readers who do not spend their evenings reading RFCs, here is the shape of it in plain language. These are general, long-standing internet protocols rather than anything Hytale invented, which is precisely why picking them is a good sign — they are the same family of mechanisms that voice and video calling have used for well over a decade. STUN is how a machine behind a router discovers what it looks like from the outside — the public address and port that the rest of the internet would need in order to reach it. On its own it is only discovery. TURN is the fallback: a relay server in the middle that both sides can reach outbound, forwarding traffic between them when they cannot reach each other directly. It always works if both parties can reach the relay, at the cost of routing your traffic through a third machine. ICE is the framework that ties them together. It gathers every candidate route both sides might use, tries them, and picks one that works. RFC 8445 is its specification. The phrase "replacing the legacy hole-punch path" tells you what it displaced. The older approach guessed at how routers would behave and tried to open a path by timing outbound packets from both ends. It works beautifully on cooperative routers and fails silently on uncooperative ones, and it has no answer at all when a direct path is genuinely impossible. That is the entire reason a VPN overlay like Tailscale became the community's standard answer: it sidestepped the problem instead of solving it. Nothing regresses if ICE fails The third line is the quietly reassuring one: "Failed ICE attempts fall back to the existing direct connection race." This is an addition on top of what already existed, not a replacement that leaves you worse off if it misbehaves. If ICE cannot establish a path, the connection attempt drops back to the mechanism that was already there. The worst realistic outcome of Hotfix 1 for a connection that worked before is that it still works. That is the right design for a networking change shipped five days before a stable release, and it is worth saying out loud, because "they rewrote the connection layer the week of launch" is otherwise a sentence that would make any server operator nervous. The Caveat That Will Catch People: The Relay Is UDP Only Here is the honest boundary on a triumphant headline, and it is stated openly in the patch notes rather than buried: "The relay uses UDP only, so networks that block UDP relay traffic cannot use it." Read that as written. The TURN relay — the fallback that makes "no matter your network" true for the hard cases — is UDP only. If your network blocks UDP relay traffic, the fallback is not available to you. You still get the direct paths ICE can find, and you still get the old direct connection race behind them, but the guaranteed-to-work relay is not in play. Which networks does that describe in practice? The patch note does not enumerate them, so neither will we with any certainty. What we can say is that restrictive UDP handling is a well-known characteristic of managed networks generally: school and university networks, corporate networks with egress filtering, some public and guest Wi-Fi, and certain mobile and ISP configurations. If you have ever found that voice chat, game traffic or a VPN behaves oddly on a particular network but web browsing is fine, that network is a candidate. The practical version of this advice: if you are on a locked-down network and joins still fail after Update 6, you have not found a bug. You have found the documented limit of the relay. That is a much better place to be than the old situation, where the failure had no name at all, but it is still a failure. Our "Failed to Connect to Server" troubleshooting guide remains the right place to work through the rest of the possibilities before you conclude it is your network. And if it is your network: this is one of the two cases where the old advice still applies. A VPN overlay such as Tailscale builds its own tunnel rather than relying on the relay, so it remains a legitimate answer for people the relay cannot reach. The other route, if you want a shared world that does not depend on either party's home network at all, is a dedicated server — our guide to finding and joining Hytale servers covers that path. Double NAT Still Does Not Work The second boundary is called out explicitly, as an asterisked footnote in the notes themselves: Known limitation: "Double NAT" setups still cannot connect. We hope to ship a solution in the Update 7 pre-releases. Double NAT is what you get when your traffic passes through two layers of address translation before it reaches the open internet — most commonly an ISP-supplied modem/router running in router mode with your own router plugged in behind it, and also the shape of many carrier-grade NAT arrangements where an ISP shares one public address across many customers. Each layer of translation makes the "what does the outside world see" question harder to answer, and two layers defeats the mechanisms that handle one. Two things are worth noting about how this was communicated. First, they said it. A studio shipping a triumphant "play together, no matter your network" headline had every commercial incentive to leave the exception out of the patch notes, and it is in there, flagged, in the same section as the good news. Second, the language on the fix is "we hope to ship a solution in the Update 7 pre-releases" — a hope, with a target window, not a commitment. Treat it as exactly that. If you are on a Double NAT setup today, Update 6 does not fix you, and Update 7 might. Concretely: if you are behind Double NAT, keep Tailscale. Nothing in this hotfix reaches you, and the workaround you were using is still the workaround you need. Hytale's support documentation independently lists "Multiple routers (Double NAT)" as a cause of share code generation failure, and describes the CGNAT case as "Your ISP shares one public IP among multiple customers. UPnP port mapping won't work." Those descriptions predate the hotfix, but they are a useful way to recognise whether you are in the affected group. The point of a networking fix is the part nobody sees: two people in the same dungeon who previously could not get into the same world. A general official Hytale screenshot, not a Hotfix 1 screenshot. The Developer Post That Came First The change was announced before it shipped. On Thursday August 20, 2026, at 15:41 UTC, Alex (@MelodicAlbuild), whose verified account carries the bio "Engine Developer @Hytale", posted a full explanation. Note the sequencing carefully, because it is easy to get backwards: this post predates the Hotfix 1 section by two days. He announced what was coming; the hotfix shipped it on August 22. "Yesterday the @Hytale team posted about a test that the team was doing in preparation for Update 6. Today, I'm here to tell you what it was. "In Update 6 we will be releasing network improvements that allow even more people to connect with their friends without needing external apps. This means that players that haven't been able to connect with friends because of NAT issues, will now be able to connect without needing to use other software, commonly Tailscale. We implemented a well-known set of protocols, called STUN and TURN to help connect players no matter where you are in the world, what your NAT type is, and who you're playing with." "There are, however, still a couple instances where you may not be able to play with a friend. Specifically "Double NAT" does not work yet. This is something I, and the rest of the team, are actively exploring, and we hope to have a solution for it out in the Update 7 Pre-Releases." "Thank you all for your continued conversations in the community about these issues, and I, alongside the team, hope that this makes it easier for all of you, and your friends, to play together!" Three details in there are worth pulling out. Tailscale is named by the developer, not just inferred by us. The phrase is "without needing to use other software, commonly Tailscale". This is not a community reading of a vague patch note; the engineer who built it named the workaround he was replacing. That is unusual and welcome — most studios describe the fix and never acknowledge the thing people were doing instead. The Double NAT caveat was disclosed at announcement time, not after. It appears in the same post as the good news, two days before the patch notes repeated it. Consistency between an engineer's post and the eventual patch notes is a small thing, but it is the kind of small thing that tells you the disclosure was deliberate rather than forced. The framing is "even more people", not "everyone". Careful wording from someone who knows exactly where the remaining holes are. Hytale's Own Documentation Has Not Caught Up This is the part that will confuse people for weeks after launch, and it is worth stating plainly. Hytale's official support article "Joining Friends" — at support.hytale.com — was last updated on July 28, 2026. That is roughly four weeks before the hotfix. It still documents the old system, and it still recommends Tailscale by name: "Tailscale creates a peer-to-peer VPN tunnel between devices using WireGuard." "Once connected, Hytale automatically detects Tailscale addresses and includes them in the share code." It also describes the mechanism that ICE displaces: "Uses UPnP (Universal Plug and Play) to automatically configure your router" "The share code contains encrypted connection candidates including your local network addresses, public IP (via UPnP), and any VPN addresses." So the situation, as of 25 August 2026, is that the official help documentation describes a system the pre-release branch has already moved off. We are dating that observation deliberately: support articles get updated, and this one presumably will be. If you are reading this weeks later, check the article's own "last updated" stamp before assuming it is still behind. To be clear about why this is worth a section rather than a snipe: it is not a scandal. Documentation lagging a pre-release hotfix by three days is completely normal, and the article was written against the shipping stable build rather than the pre-release branch. But it does mean that for some period after August 27, the official docs and the search results that quote them will keep telling people to install a VPN that most of them no longer need. What we deliberately are not going to tell you is how the share code itself changes, because the patch notes do not say. Hotfix 1 describes the join path — ICE, STUN, TURN, relay fallback. It says nothing about the format or contents of a share code. Whether share codes still carry the same candidate list, whether they still pick up Tailscale addresses if you happen to have Tailscale installed, and whether the UPnP path is still used as one candidate among many are all open questions that we cannot answer from the source material. If you want a claim about share code internals, wait for the docs to be updated rather than trusting anyone's guess. One piece of the old documentation that has not been superseded and still deserves its bold text: "Share codes contain your IP address. Never post them publicly, paste them in public chats, or show them on stream." Nothing in Hotfix 1 contradicts that, and until official documentation says otherwise, keep treating a share code as sensitive. What this means for our own guide Our guide to playing Hytale with friends: share codes vs dedicated servers is the piece on this site most affected by Hotfix 1. Its structure still holds — the choice between hosting a world yourself and running a dedicated server is exactly the same choice, and the dedicated-server half is entirely unchanged. What changes is the calculus on the share-code half: the "if your NAT type blocks this, use a VPN overlay" branch of that decision tree now applies to a much smaller group of people, essentially those on Double NAT and those on networks that block UDP relay traffic. We would rather tell you that here than let you read a stale recommendation without a warning attached. The Rest of Hotfix 1: Three Stability Fixes The networking change is the headline, but Hotfix 1 also carries three player-facing stability fixes. All three are quoted in full below, because all three are the kind of thing that generates support tickets on a public server. 1. The skin mod crash on world join "Fixed a crash on world join when a server or world runs several large skin mods at once. Textures that overflow the texture atlas are now skipped with a logged warning instead." This is the most operationally relevant of the three, and the fix is more interesting than the crash. The trigger is several large skin mods at once — a combination, not a single bad mod, which is why it will have been hard to pin down. Textures were overflowing the texture atlas, and an overflow was fatal on join. The new behaviour is a graceful degradation: overflowing textures are skipped, and a warning is written to the log. Note precisely what that means for a heavily modded server. You no longer crash — but you also do not get every texture. Something is being dropped, and the only way you will know which is to read the log. If you run a large modpack with multiple skin mods, check your log after your first world join on the new build; a clean join is no longer proof that everything loaded. If you are already fighting a modpack that misbehaves, our guide to mod conflicts and asset patching covers how to narrow down which mod owns a given asset. 2. Clean disconnects on server shutdown "When a server shuts down, players now get a clean disconnect instead of waiting for their connection to time out." Small, and disproportionately good for anyone who restarts a server on a schedule. Previously, shutting down left connected players hanging until their client gave up on its own — which looks, from the player's side, exactly like the server having a problem rather than the server having been restarted deliberately. A clean disconnect turns an ambiguous freeze into an unambiguous event. If you run scheduled restarts, this is a quality-of-life win you will feel every single restart, and it pairs with the operational sequence in our Update 6 launch-day checklist. 3. Switching a shared world back to private takes effect immediately "Switching a shared world back to private now takes effect right away." This one is a privacy fix wearing the clothes of a UI fix. The implication of "now takes effect right away" is that it previously did not — that there was a window between flipping a shared world back to private and that change actually applying. For anyone who shares a world with friends occasionally and expects "private" to mean private the instant they click it, that window mattered. It is closed. The Only Modder-Facing Change, and Why "Requires No Changes" Matters This Week Hotfix 1's Modder-Facing Changes section contains exactly one entry, under Protocol & Networking: "ServerListener now exposes optional wire-byte counters through default methods. Existing implementations require no changes." Two halves, and the second half is the one to read twice. The capability: ServerListener gains optional counters for wire bytes. That is a measurement hook — how much data is actually going over the connection. For anyone writing monitoring, diagnostics or bandwidth-accounting tooling, it is a genuinely useful thing to have exposed rather than estimated, and it arrives in the same build as a networking overhaul, which is a sensible pairing: a new connection path is exactly the thing you want to be able to measure. The safety guarantee: "Existing implementations require no changes." The counters are exposed through default methods, which is the mechanism that makes that guarantee true — an interface method with a default implementation can be added without breaking classes that already implement the interface, because those classes simply inherit the default and carry on compiling. The timing is what makes this worth a section of its own. It is August 25. Update 6 goes stable on August 27. A plugin author has days, not weeks. A build that added a required interface method in that window would force every ServerListener implementation in the ecosystem into an emergency recompile with no time to test it. Instead, the one modder-facing change in Hotfix 1 is additive and opt-in. If you do not want the counters, you do nothing. Scope this carefully: "non-breaking" describes Hotfix 1, not Update 6 This is the sentence we most need you not to misread, so here it is on its own. Hotfix 1 is non-breaking. Update 6 as a whole is not. The pre-release run leading up to August 27 removed public API repeatedly. Part 13, from August 20, removed the BlockChunk per-block light accessors and WorldChunk.toHolder among others, and renamed several members that appear in asset definitions as well as in code. Part 12, from August 13, and Part 11, from August 6, carried their own removals. If you have a plugin to migrate, the work is in those parts. Hotfix 1 adds nothing to that pile — that is all "non-breaking" means here, and it should be a relief rather than a reason to skip the migration you already had to do. Why You Cannot Find a Hotfix 1 Post in Hytale's August Archive Every week we have to explain this, and every week it catches somebody, so here it is again. Go to hytale.com/news/archive/2026/8 looking for the Hotfix 1 announcement and you will be told "No posts found for this month". Nothing is broken and nothing was taken down. Every part of the Update 6 pre-release run is a section inside one single post, published on May 28, 2026, at one URL, which is edited as each new part is added. A post from May never generates an August archive entry, however many times it is updated. The post's own intro says exactly this: "Hi everyone! Below are the pre-release patch notes for Update 6, which we will update weekly." As of today the sections run, newest first: Hotfix 1 (August 22), Part 13 (August 20), Part 12 (August 13), Part 11 (August 6), Part 10 (July 30), and then Parts 9, 8 and 7, with Part 7 dated July 9. Two consequences follow. The first is that the rolling page is not an archive — the version you read today is not guaranteed to sit there unchanged, which is exactly why we write each part up separately and keep them readable here in full. The second is more immediate: because the change is buried in a section of a May post, the version trackers and search engines that people rely on to answer "what is the newest Hytale build" have largely not registered it. As of today, the usual community version trackers are stale by months, and a search for the latest patch notes still tends to surface Part 12. If you found this article because a search engine told you Part 12 was current, that is why. And for anyone still on the stable branch who wants to see any of this before Thursday: "To access Pre-Release version: Enable via Launcher → Settings → Pre-Release" Is Hotfix 1 the Last Pre-Release Before Update 6 Ships? Our read, explicitly labelled as our read: probably, and Hytale has not said so. The facts are these. There is no Part 14 on the page as of today, August 25. The newest section is Hotfix 1, dated August 22. Update 6 goes stable on Thursday August 27. The parts arrived on a Thursday cadence through August — Part 11 on the 6th, Part 12 on the 13th, Part 13 on the 20th — and the next Thursday slot is launch day itself. That is arithmetic, not an announcement. Nothing in the patch notes calls Hotfix 1 the final pre-release build, and it would be entirely unsurprising for another hotfix to appear mid-week; Hotfix 1 itself landed on a Saturday, which is proof that the Thursday pattern is a habit rather than a rule. Treat this as our inference and plan accordingly: if you are a plugin author or a server operator, work on the assumption that the API surface in front of you now is the surface you ship against, and be pleasantly surprised if something else lands. The Launch Date, and the Oddity Around It The anchor for the whole week was set on Monday August 17, 2026, when the verified @Hytale account posted: "Update 6 releases August 27 — Mod Browser, Hardcore Mode, new Creative Tools, and so much more! Note to Modders/Server Operators: please check the warnings and bug fixes to ensure you are prepared." The date is officially confirmed, from the official account. Here is the oddity worth knowing about: that date appears nowhere on hytale.com. Not on the front page, not on the news page, not on the support site. If you have been checking the website for confirmation and coming away empty, you are not missing a page — it genuinely is not there. Our Update 6 release date explainer tracks that situation, and we are not going to state a launch time of day, because only the date has been published. The closing instruction in that post — "please check the warnings and bug fixes to ensure you are prepared" — is effectively the reason this article exists. Hotfix 1 is part of the warnings and bug fixes. A Different Reason Joins Fail on Thursday One coda, walled off deliberately, because conflating it with everything above would be a disservice. Everything in this article is about NAT and network path — the reasons two machines that both want to talk cannot find a route to each other. Hotfix 1 makes that class of failure much rarer. There is a second, completely separate class of join failure that has nothing to do with your router: a client and a server running different versions. When the two are out of step they do not connect, no matter how perfect the network path between them is. This matters on Thursday specifically, because a server left un-updated when the stable build lands is a server people cannot join — and the error a player sees may look superficially similar to the NAT failures this hotfix fixed. They are different problems with different fixes. If joins fail after August 27, establish which one you are looking at before you start changing router settings: a mismatch affects everyone identically regardless of their network, while a NAT problem affects some players and not others. Our launch-day checklist covers the operational sequence for the day, and our "Failed to Connect to Server" guide covers telling the failure modes apart. FAQ Do I still need Tailscale to play Hytale with my friend? Per the Update 6 Part 13 Hotfix 1 patch notes dated August 22, 2026, no: "Players who couldn't join friends because of their NAT type can now connect without tools like Tailscale." Player-hosted joins now use ICE (RFC 8445) with STUN and TURN, and a TURN relay carries the connection when no direct path is available. Two exceptions remain — "Double NAT" setups still cannot connect, and the relay is UDP only, so networks that block UDP relay traffic cannot use it. If you are in either of those groups, keep Tailscale — for you the old workaround is still the answer. Note also that, as of 25 August 2026, Hytale's official support documentation still recommends Tailscale, because it was last updated on July 28, 2026, before this change. Does this mean my dedicated Hytale server no longer needs port forwarding? No. The patch note is scoped to "player-hosted joins" — the path where one player hosts a world and a friend joins it. Nothing in Hotfix 1 changes what a dedicated server needs in order to be reachable. If you run a dedicated server, your existing networking setup is unaffected by this change. What is ICE, STUN and TURN in Hytale? They are standard internet protocols, not Hytale inventions. STUN lets a machine behind a router discover how it appears from the outside. TURN is a relay server that forwards traffic between two parties when they cannot reach each other directly. ICE, specified in RFC 8445, is the framework that gathers all the possible routes, tries them, and selects one that works. The patch notes say this combination replaces "the legacy hole-punch path", and that "failed ICE attempts fall back to the existing direct connection race". Why does the relay not work on my school or work network? Because of a documented limit: "The relay uses UDP only, so networks that block UDP relay traffic cannot use it." On such a network you still get whatever direct paths ICE can establish, plus the existing direct connection race as a fallback, but the TURN relay that guarantees a connection in the hard cases is unavailable. The patch notes do not list which networks are affected, so we are not going to either — but restrictive UDP handling is a common characteristic of managed networks. When will Double NAT be fixed in Hytale? Unknown, with a stated hope. The patch notes say: Known limitation: "Double NAT" setups still cannot connect. We hope to ship a solution in the Update 7 pre-releases. Engine developer Alex (@MelodicAlbuild) said the same on August 20, 2026, calling it something the team is "actively exploring". A hope with a target window is not a commitment to a date. Does Hotfix 1 break my Hytale plugins? Hotfix 1 itself contains exactly one modder-facing change: "ServerListener now exposes optional wire-byte counters through default methods. Existing implementations require no changes." That is additive and non-breaking. This says nothing about Update 6 as a whole, which removed public API repeatedly across the pre-release run — Part 13 and the parts before it are where your migration work is. Why is there no Hotfix 1 post in Hytale's August news archive? Because every part of the Update 6 pre-release run is a section inside a single post dated May 28, 2026, which is edited weekly rather than replaced. A May post never creates an August archive entry, so hytale.com/news/archive/2026/8 reports "No posts found for this month" even though Hotfix 1 was published there on August 22. Is there a Part 14? Not as of today, August 25, 2026. The newest section on the pre-release page is Hotfix 1, dated August 22, sitting above Part 13 from August 20. Our reading — and it is our inference, not an announcement — is that Hotfix 1 is likely the last pre-release build before Update 6 goes stable on August 27, because the next Thursday in the cadence is launch day itself. What To Do With This Before Thursday Four things, in the order they matter. If you host for friends, stop reaching for the VPN first. After August 27, try the plain join before you install anything. The mechanism that made a VPN overlay necessary has been replaced, and the number of people who still need one has shrunk to those on Double NAT and those on networks that block UDP relay traffic. If you run a dedicated server, change nothing about your networking on the strength of this. Hotfix 1 is about player-hosted joins. Your reachability setup is untouched and still required. If you run a heavily modded server, read your log after the first world join. The skin mod crash fix skips overflowing textures with a logged warning rather than crashing. A successful join no longer means everything loaded, and the log is now the only place that difference is visible. If you maintain a plugin, finish the Part 13 migration and ignore Hotfix 1. The one modder-facing entry here requires no changes from you. The removals that do require changes are in the earlier parts, and you have days rather than weeks. Beyond that, this is a good change and it deserves to be called one without hedging it to death. A networking layer that only worked on cooperative routers has been replaced with the standard, well-understood set of protocols that the rest of the internet solved this problem with years ago, the fallback path is intact so nothing regresses, the remaining limitations were disclosed rather than buried, and the engineer who built it named the workaround he was putting out of business. Five days before a stable release, that is about as good as a patch note gets.