While often invisible to players, multiplayer game infrastructure that supports secure player connectivity and game stability is as crucial as the gameplay itself.

One key component in this infrastructure that is often overlooked is the relay server.

In this post, we'll delve into the role of relay servers in peer-to-peer networking, and touch upon the specifics of baseline relay services such as Unity, Steam, and Epic Online Services and their use cases, alongside where and when improved relay services are preferable, while touching on the broader topic of game server hosting and why servers sometimes go offline.

What is a Relay Server in Multiplayer Games?

In short, in the context of online games, a relay server elevates and solves the common issues of peer-to-peer by acting as an "intermediary" server that forwards communication between players.

In other words, relays act as bridges (or routers/proxies), relaying messages between peers that cannot establish direct connections. By relaying data between players, they play a crucial role in establishing connections between players who may encounter obstacles such as firewalls or network address translation (NAT) issues. These NAT issues are so extremely common that companies such as Xbox or PlayStation will have entire support pages dedicated to them.

Relays usually improve the gaming experience by reducing latency and packet loss, provided that the relay server itself is robust, and that the orchestration service behind it places relays geographically close to the players. Otherwise, the relay will introduce latency, potentially reducing fairness between players who are near the relay and those who aren't (if one of the game clients is acting as the authoritative server).

Understanding Peer-to-Peer Architecture in Modern Gaming

Peer-to-peer networking architecture is an entrenched part of multiplayer games' backend structure. In a P2P setup, one of the players' machines acts as the server, handling the game logic and synchronization for all participants.

This approach often minimizes developers' costs, as a player handles the hosting of the match, and it is more straightforward to implement. For smaller titles, or studios who find hosting fees too steep, it is a great choice.

However, it often results in a less than ideal play experience, with inconsistent game performance, particularly if the host player lacks a high speed internet connection or adequate hardware. Worse yet, P2P can easily be abused by cheaters to manipulate the game and by attackers who can target your players. That makes it a poor solution for any studio looking to make competitive play a long-tail retention strategy, and it lowers long term retention as highly engaged players stop seeing a return on their continued investment in the game.

Titles big and small, from indies to AAA, are shifting toward either a full or hybrid game server model that combines authoritative game servers with relays. For a breakdown of where each model fits, see our guide on [authoritative servers, relays, and peer-to-peer](https://edgegap.com/blog/explainer-series-authoritative-servers-relays-peer-to-peer-understanding-networking-types-and-their-benefits-for-each-game-types).

Cheating Techniques in Peer-to-Peer Networking

A major challenge of P2P is bad actors exploiting the vulnerabilities of P2P hosting. Cheaters have devised various methods to gain an unfair advantage or disrupt the gaming experience for others:

• Lag Switching: Cheaters can intentionally introduce lag to disrupt the flow of the game. By delaying their data transmission, they can "freeze" the game momentarily and make moves without other players being able to respond in real time.

• Data Manipulation: Since game data resides on individual clients, a cheater can modify their data to give themselves infinite health, unlimited ammunition, or even change their location instantly.

• Ghosting: In games where players are supposed to have limited visibility of the map or other players, a cheater could gain complete visibility, giving them an unfair advantage.

Why Do Game Servers Go Down or Shut Down?

Server downtime is always a frustrating period of time for gamers. It often occurs due to maintenance, updates, unforeseen issues, or even cyber-attacks. In some cases, game servers are permanently shut down, a decision typically driven by the game's declining player base, financial considerations, or the release of sequels and newer titles, and by the limited resources of the studio.

Relay Service: Free or Not?

Relays are game servers used to help players connect without generating compute cost, meaning players themselves remain the gatekeepers to authorize the game's actions. As such, the servers needed are minimal. Companies such as Epic, with Epic Online Services, and Steam, with Steamworks, provide game developers with relays free of charge when using their backend solutions.

While a great stepping stone, these services are extremely limited in terms of locations, and aren't known to be the most reliable. Here's the breakdown of why free relay services aren't ideal for commercially produced games:

• Increased Latency: Introducing an intermediary can increase the game's latency if the relay server is geographically distant from the players. It is therefore critical to pair it with an automated orchestration system that deploys relays nearest to users. With a low coverage density, these services are known to introduce latency.

• Reliability: If a relay server goes down, it will disrupt the gaming experience for connected players. If all relays are hosted on the same provider and an outage occurs, all players will be taken offline. Therefore, only a multi-cloud relay orchestration network can ensure high reliability.

• -Authority: Relay networks are not authoritative servers. They can't replace a central server authority for highly competitive, fast paced games.

What a Fallback to Relays Looks Like in Production

Those first two points are easy to nod along to in the abstract. A 2026 incident on Steam Networking made them concrete.

Starting around mid-March 2026, players began reporting that peer-to-peer matches had gotten dramatically worse. In Street Fighter 6, Israeli players connecting PC to PC saw pings of roughly 120 ms, while European players on the same title saw 60 to 80 ms. The same Israeli players connecting to a PlayStation 5 through cross-play saw a ping of 5 to 10 ms.

The players' connections were not the problem. Steam's "Share IP Address" setting was not being honored, so attempts at a direct connection silently fell back to Steam Datagram Relay, and the nearest relay was not close enough to make up the difference. The pattern held across Warhammer: Vermintide 2, Deep Rock Galactic, Melty Blood and others, with reports coming from Israel, Egypt, and China. One regression in a shared networking layer, felt in every game that depended on it.

The routing behavior itself was deliberate. Valve's own peer-to-peer documentation notes that on Steam they always relay traffic and do not share IP addresses between untrusted peers, so that malicious players cannot launch DoS attacks. That is a sound reason to prefer a relay. It also means the relay path has to be fast everywhere your players are, because it is the path players will get.

The part worth sitting with is what studios could do about it. Very little. Capcom could not patch its way out, because the routing decision was not Capcom's to make. Players improvised, first with a community mod and then by manually copying `steamwebrtc64.dll` into their game folders, a workaround that only worked when both players did it. Valve confirmed the bug on GitHub, shipped a fix in a Steam client beta, and then in the main client. Roughly three months passed between the first report and the shipped fix (GameNetworkingSockets issue #398).

Free relays are not free of consequences. They come with someone else's routing decisions, on someone else's timeline, measured against someone else's map of where players actually live. That last part is the one studios underestimate, and it is why coverage density matters more than any single benchmark. For more on that, read our take on why [the only real answer to latency is more locations](https://edgegap.com/blog/for-true-latency-reduction-the-only-answer-is-more-locations).

Are Unity Game Relays Free?

The answer used to be "no, and it scales with usage." As of 2026 the answer is different, because Unity no longer offers game server hosting at all.

Multiplay Game Server Hosting was deprecated on April 1, 2026, following a migration deadline of March 31. Unity's own service notice puts it plainly: "As of April 1st 2026 Multiplay Game Server Hosting by Unity has been deprecated. Customers can no longer scale new game servers or make new allocations to the Multiplay service." Studios that declared an intent to migrate to Multiplay by Rocket Science before the cutoff were allowed to keep running during their transition.

Relays did not go away with it. Unity Relay, along with Lobby, Friends, and Vivox, remains part of Unity Gaming Services, and Relay is still priced on usage: bandwidth, concurrent users, number of requests, and other variables. It aims to simplify establishing and maintaining network connections for multiplayer games, and it is a more reliable and scalable option than raw P2P. Developers should still weigh what it costs at scale, particularly for games with large player bases or a high volume of network traffic.

It's worth sitting with what that combination leaves a Unity studio holding. The relay is still there. The authoritative hosting is not. Teams that had planned to start on Relay and graduate to Multiplay once their game got competitive now have to choose a hosting partner regardless, and they are choosing it under a deadline rather than on their own schedule.

Relays for WebGL Games

WebGL games are especially susceptible to issues with traditional relays. WebGL games tend to have easily 2 to 5 times more latency, because on WebGL a websocket cannot NAT punch through directly. It needs a relay server (STUN server) for NAT (network address translation).

This further reinforces the need for an orchestration service that can help overcome this latency challenge, such as Edgegap, which deploys nearest to users on a highly dense worldwide network to mitigate this inherent problem of multiplayer WebGL games.

Introducing the Network of Relays: A Potential Solution

A convenient and easy to integrate way to counter some of the vulnerabilities of P2P hosting is by using a network of relays.

Instead of players connecting directly to each other, they connect to relay servers, which then handle the data transmission between players. These are much easier to integrate than authoritative servers, cheaper to run, and provide significant benefits over pure P2P hosting.

Benefits include:

• Shielding of IP Addresses: Players' IP addresses are hidden from each other since they only connect to the relay server. Relays prevent IP-based attacks and safeguard player privacy.

• Fairness in Connection Quality: Since everyone connects to the relay, any network advantages (like being the host in a P2P scenario) are neutralized. Everyone experiences a more consistent connection quality.

• NAT: By design, relays solve P2P's well-documented NAT connectivity issues by acting as a go-between for users, delivering seamless connections and player experience. Specifically, they overcome NAT traversal and firewall restrictions.

• Potential for Cheating Detection: Relay servers can be equipped with anti-cheat algorithms that monitor game data in real time. Suspicious patterns or anomalies can be flagged, making it easier to detect and deter cheaters.

Those benefits hold on one condition, which the Steam Networking incident above illustrates well: the relay has to be close to the player. A relay that neutralizes host advantage but adds 60 ms for an entire region has traded one fairness problem for another.

Upgrading from Relay: Authoritative Game Servers?

A relay changes who your traffic flows through. It does not change who decides what is true. Almost every remaining limitation of a relay setup traces back to that one distinction.

• The cheats from earlier still work. Game state lives on a player's machine, so data manipulation, lag switching, and ghosting are all still on the table. A relay hides IP addresses and solves NAT. It does not validate a single packet of gameplay.

• Every packet takes two hops. Traffic goes player to relay to player, rather than player to server. The relay's placement sets the latency floor for the entire match, and no netcode trick recovers what a badly placed relay adds.

• The host is still a single point of failure. When the hosting player quits, crashes, or rage-closes the game, the match either dies or limps through a host migration. Neither reads well in a ranked mode.

• The host's hardware caps the game. Simulation tickrate, entity counts, player counts, and bandwidth ceiling are all decided by whichever player got picked, on whatever connection they happen to have.

• There is no server side to build on. No authoritative validation, no persistence between matches, no server-owned telemetry, no replays, no controlled tickrate. Systems that competitive games are expected to ship with have nowhere to live.

Game server hosting is the answer to that list. It refers to providing online infrastructure for multiplayer games, including dedicated servers that run 24/7, ensuring players can connect and play together regardless of location. Hosting can be managed by game developers themselves, or by third-party companies.

Effective game server hosting is crucial for a game's online components, impacting everything from latency to matchmaking. As multiplayer experiences become more central to gaming, the quality, reliability, and scalability of server hosting become paramount for developers and players alike.

It also puts the routing decision back in the studio's hands. When a region suddenly sees 120 ms, the team that owns the deployment is the team that can fix it, rather than filing a report and waiting on someone else's client update.

The historical objection to all of this was cost and operational overhead. Running dedicated servers meant provisioning capacity you paid for whether players showed up or not, and hiring the DevOps skills to keep it standing. That is the calculus that pushed a generation of studios toward P2P and free relays in the first place, and it is the part that has changed most. Just-in-time [orchestration](https://edgegap.com/platform/orchestration-hosting) boots a server on demand in roughly 3 seconds, across [615+ locations worldwide](https://edgegap.com/blog/world-s-largest-distributed-network-edgegap-continues-to-expand-with-615-locations-worldwide), at a [single price regardless of region](https://edgegap.com/pricing). One AAA studio measured a 58% average latency reduction after moving to that model, with sub-50ms latency reaching 78% of its playerbase ([case study](https://edgegap.com/gaming/case-studies/AAA-Studio)).

Which reframes the comparison. A relay's appeal was never that it produced better matches. It was that it was cheap and easy while dedicated servers were neither.

For more details on why, and when, authoritative servers may be better suited than relays, see our Networking Types guide.

Conclusion

Understanding the nuances of game server infrastructure, from relay servers to hosting solutions, is vital for game developers and the gaming community.

Basic relay services offer streamlined solutions, and they come with costs and considerations for your game and your players' experience. Those costs are not always visible on an invoice. Sometimes they show up as a region of players who quietly stop queueing.

Relays have a real place. They fix NAT, they hide IP addresses, they are quick to integrate, and for a co-op title or an early build they are often the right call. A relay network with automated orchestration on a dense, regionless footprint is a substantial upgrade over both raw P2P and a thin free tier.

What a relay cannot do is own the game. The moment competitive integrity, persistence, or consistent performance across regions starts mattering to retention, the deciding factor stops being how traffic is routed and starts being where the simulation runs. Two of the three problems in this article, a region stuck at 120 ms and a studio unable to fix its own netcode, came down to not owning that answer.

Learn more about Edgegap's orchestration and game server hosting, read the case studies, or dive into our Documentation.