Protecting a Hytale server from DDoS attacks

A Hytale server that drops every connection at the same moment in the middle of an evening session, stays unreachable for a few minutes and then comes back on its own rarely has a hardware problem. In almost every case an attack is running. This article shows how to protect a Hytale server from DDoS attacks: first what you can configure yourself at no extra cost, then the point where those measures technically end, and finally what has to happen in the network in front of the server so that the server stays reachable.

Everything here refers to the official dedicated server from Hypixel Studios, that is HytaleServer.jar together with Assets.zip on Java 25, running on Debian 12, Debian 13, Ubuntu 22.04 LTS or Ubuntu 24.04 LTS. The commands are written for root, as a normal user you prefix them with sudo. Hytale is in Early Access and moving fast, so every statement about the game in this article carries a date, and anything that is not officially documented is explicitly marked as an expectation or as a community source. If the attack is running right now, one more rule applies: measure first, change second. A hard restart under load discards everything that happened in the world since the last save point, and the measurements of the incident are gone with it.

Why Hytale servers are deliberately taken down with DDoS attacks

A Hytale server is an audience at a fixed address, and that audience is replaceable. Anyone who fails to reach their regular server three evenings in a row goes and finds another one. That is the entire business model behind attacks on community servers: it is not about data and not about extortion, it is about players who move on. A booter service that hammers an address for a few euros a month asks its customer for neither skill nor effort, and the damage happens again with every outage.

Hytale adds a particular twist: the server code is public. Hypixel Studios announced the Hytale Shared Source program in June 2026 and publishes the full server source, the network protocol and the assets through GitHub, accessible to anyone holding a valid game license. For server operators that is a win, because plugins are built against real interfaces. For the attacking side it means nobody has to guess the protocol any more. Whoever wants to know where the connection handshake costs CPU time can simply read it. What technically happens during such an attack is explained in the article What is a DDoS attack?.

Where Hytale stands as of September 27, 2026

Hytale has been in Early Access since January 13, 2026, available for Windows, macOS and Linux, and it passed one million players in the days after launch. The road there was unusual, and it explains why older articles about Hytale are frequently no longer correct.

The practical consequence of this timeline: a Hytale server today is not a Hytale server from January. With Update 6 the network protocol changed from hytale/2 to hytale/3, and according to the official patch notes of August 27, 2026 servers and plugins need a rebuild before they will connect. Anyone planning for availability therefore plans not only against attacks but also against protocol changes.

Why October 12, 2026 is the critical date

Large content updates work like a second launch day. They bring old players back, pull new ones in, and for a few days reachability decides which community server grows out of that wave and which one misses it. This pattern is documented for other games: Palworld reached millions of players within days in January 2024, and the community servers of that launch phase were attacked most heavily at exactly the moment when they had most to lose. The mechanics behind it are described in detail in Protecting a Palworld server from DDoS attacks and carry over to Hytale one to one.

That leads to an uncomfortable truth about scheduling: protection ordered on October 12 is too late. A line, a protected IP, a rule set per port and a baseline measurement for normal operation all need lead time, because without comparison data they cannot be tuned sensibly. Starting two weeks before a large update leaves enough room. Starting on the day of the update means tuning blind.

The ports a Hytale server actually needs

A Hytale server needs exactly one open port: 5520 UDP. Game traffic runs over QUIC, which means over UDP, and TCP is not required for game traffic. Anyone who opens only TCP sees the same picture as with a closed firewall: players run into a timeout. The default bind is 0.0.0.0:5520, a different port is set at start time with --bind.

This table is shorter than for most other games, and that is the single most important difference. A Counter-Strike server answers status queries in the Steam A2S format, a Minecraft Bedrock server answers an unconnected ping, a Palworld server keeps a separate query port open. For Hytale, no port other than 5520 UDP is described in the public documentation: no query port, no RCON port, no REST interface in the shipped state. Everything a Hytale server exposes sits on a single UDP port.

Hytale servers in numbers

The following values are the basis for every decision about filter rules and thresholds. The origin is listed for each one, because the origin decides how much weight it carries.

What QUIC changes about the attack surface

QUIC is a transport protocol that establishes secured connections over UDP and has the TLS 1.3 handshake built in. There is no unencrypted QUIC. For a server operator that means two things which contradict each other, and both matter.

The first one is a genuine improvement. Because UDP enforces no connection setup and source addresses can be spoofed, connectionless UDP services are the classic amplifiers for attacks on third parties. QUIC limits that in the standard itself. RFC 9000 requires in section 8.1 that a server must not send more than three times the number of bytes it received before it has validated the source address, and section 14.1 requires a client to pad its first datagram to at least 1200 bytes. Together these two rules cap the amplification factor of a QUIC service at three, while a Steam query port or a Bedrock unconnected ping reaches a multiple of that. A correctly behaving Hytale server is therefore practically worthless as a reflection amplifier. That is a structural advantage over almost every other game with UDP traffic, and it stands out clearly in comparison with Minecraft Bedrock servers.

The second one is the price you pay for it. A QUIC connection setup costs the server CPU time, because it includes a TLS 1.3 negotiation with asymmetric cryptography. A single spoofed packet cannot force a handshake, but a flood of genuine connection attempts from a botnet can. The attacker spends CPU time as well, and exactly that ratio is what decides: as long as the server does more work per connection attempt than the attacker, the attack is economical. A flood of connection attempts therefore does not load the line, it loads the processor, and it looks like nothing at all in the bandwidth graph. This is the same mechanism known on Minecraft as nullping and handshake flooding, described in detail in Minecraft DDoS protection and nullping protection.

The part of this that you can actually use is the 1200 byte rule. A new connection attempt has to arrive as a datagram of at least 1200 bytes, otherwise by the standard it is not a valid connection setup. Ongoing game traffic on the other hand consists mostly of small packets. That distinction can be turned into a filter rule, and we get to it below.

What is not publicly documented about Hytale

This list belongs in an honest article, because it marks the places where you must not rely on numbers. Everything below is not officially documented as of September 27, 2026:

• Whether the server uses QUIC Retry for address validation. RFC 9000 permits a Retry packet with a token in section 8.1.2, with which a server validates the source address before binding resources. Whether Hytale does that, and from which load level, is not documented. Assume you cannot rely on it.
• The default values of the RateLimit and ConnectionTimeouts blocks in config.json. That both blocks exist is consistent across several sources. The figures given for them are not: one source states concrete thresholds, another describes the blocks as present but without effect. That is why none of those numbers appear in this article, and why you should not plan these blocks as your defense.
• The names and defaults of the authentication modes. Community documentation of the published server code describes three modes, set through --auth-mode, with authenticated as the default plus offline and insecure for private environments and development. That is not officially confirmed. The rule derived from it is unambiguous all the same: do not change the mode on a public server.
• Details of the TLS handshake. The community protocol documentation, which is based on the published server code, describes mutual certificates, a self signed server certificate generated at startup whose SHA-256 fingerprint reaches the clients through the session service, and 0-RTT being disabled. That is plausible and fits TLS 1.3, but it is not officially confirmed, and it changes none of the measures below.
• Attack sizes specifically against Hytale servers. There are no public figures for that. The 5 to 50 Gbit/s in the table is an experience value across game server projects and expressly not a Hytale statistic.
• Packet rates per player in normal operation. There is no reliable publication for that either. That is why this article gives you no threshold to copy unchecked, but instead a method for measuring your own.

What you can do yourself before spending money

The following steps will not stop a volumetric attack, no software running on the server can do that. What they do clear away is everything below that level: port scans, floods of connection attempts from a handful of sources, takeover attempts through management interfaces you installed on top, and strangers occupying all the slots. That is the bulk of what disrupts a Hytale server day to day, and it costs about an hour.

1. Take inventory: what is listening on the server?

Before you write a single rule, look at what your server offers to the outside. Do not guess, look:

ss -lntup

The interesting column is the local address. 0.0.0.0:5520 means "reachable from the whole internet", 127.0.0.1:8080 means "local only" and needs no firewall rule. Next to the Java process of the server, a machine that has grown over time often also shows a management panel, a web server for a map view and a database. The attacker's view comes from a port scan taken from outside:

nmap -Pn -sU -p 5520 YOUR.SERVER.IP.ADDRESS
nmap -Pn -p- --min-rate 1000 YOUR.SERVER.IP.ADDRESS

The second call is the more important one. It shows what else is open, and in practice that is almost always more than expected.

2. Start the server the way it is meant to be started

Starting it is a single command. You obtain the server files through the official Hytale downloader or from your own game installation:

java -Xms2G -Xmx4G -jar HytaleServer.jar --assets Assets.zip --bind 0.0.0.0:5520

On the first run the server creates config.json, the directory logs/ and the world directory universe/. After that you sign it in to its account once, so that player authentication works. That runs through a device code in the server console:

/auth login device
/auth status

Do not set -Xmx to the machine's entire memory. The operating system, the filesystem cache and the Java runtime overhead outside the heap need room as well, and a server that starts swapping under load looks exactly like an attack to your players.

3. Leave only 5520 UDP open and close everything else

Two rules are enough. With UFW it looks like this, and in exactly this order so that you do not lock yourself out:

ufw allow 22/tcp comment 'SSH'
ufw allow 5520/udp comment 'Hytale QUIC'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

You do not need a TCP rule on 5520. If you run the server on a different port, the rule has to match the value from --bind, otherwise the start succeeds and the players still do not get in. The full walkthrough including an escape route is in Setting up the UFW firewall without locking yourself out.

For everything you additionally installed for management, the same rule applies as with any other game: keep it off the open internet, reach it through SSH port forwarding and then work locally against 127.0.0.1:

ssh -N -L 8080:127.0.0.1:8080 root@YOUR.SERVER.IP.ADDRESS

4. Whitelist, server password and player cap against slot exhaustion

Slot exhaustion is the cheapest attack on a community server and needs no bandwidth. Whoever opens enough simultaneous connections occupies every slot and locks out the actual community, without buying a single gigabit. Unlike some other games, Hytale ships the right tools for this: a whitelist in whitelist.json, a ban list in bans.json, permissions in permissions.json, and in config.json the keys Password and MaxPlayers.

{
  "ServerName": "My Hytale Server",
  "MOTD": "",
  "Password": "a value only your group knows",
  "MaxPlayers": 40,
  "MaxViewRadius": 12
}

Password is empty out of the box, so anyone with the address and the port gets in. For a closed server a password is the single most effective measure against slot exhaustion, for a public server it is the whitelist during an attack wave. And one thing has to be clear: a server password protects your slots, not your line. An attacker flooding your server does not want to join at all.

Edit these files only while the server is stopped. The running server process keeps its own state in memory and can silently overwrite changes you write into the file in the meantime when it shuts down. For changes during operation, use the console commands instead of an editor.

5. Leave authentication on its default

The default mode requires a valid Hytale account from every player. That is more than a license check: it is an access filter that makes bulk accounts expensive. An attacker who wants to occupy slots needs valid accounts for it, and those cost money. Do not take that filter out.

Community documentation describes two further modes next to the default, meant for private environments and for development, which allow joining without an account check. For a public server they are the worst reachable setting, because they turn slot exhaustion from a question of money into a question of scripting. If you switch for testing, do it on a machine that is not on the internet, and switch back afterwards.

6. Limit new connection attempts, using the 1200 byte rule

This is where the structural advantage of QUIC becomes practical. A valid connection setup arrives, per RFC 9000, as a datagram of at least 1200 bytes. Ongoing game traffic is considerably smaller. With connection tracking you can therefore tell new flows from established ones and drop everything that is new and too small. With nftables, loaded through nft -f:

table inet hytale {
    chain input {
        type filter hook input priority -10; policy accept;

        ct state new udp dport 5520 udp length < 1208 drop

        ct state new udp dport 5520 \
            meter hyconn { ip saddr limit rate over 5/second burst 10 packets } drop
    }
}

The first rule works on the UDP length, that is 8 bytes of header plus 1200 bytes of payload, 1208 together. It hits only packets that want to open a new flow and are too small to do so, and it cannot touch connected players. The second rule limits how many new connections a single source address may open per second. Five per second is generous: a real player opens one connection and keeps it. The priority -10 makes sure both rules are reached before the UFW filter chains.

A cap on the packet rate per source address on the game port itself is the third useful rule, and here it must be said plainly: the number is a starting value, not a truth.

iptables -I INPUT -p udp --dport 5520 \
  -m hashlimit --hashlimit-name hytale_udp --hashlimit-mode srcip \
  --hashlimit-above 800/sec --hashlimit-burst 1200 -j DROP

Measure a week of normal operation first, then set the limit to twice the peak you measured. There is no published reference figure for Hytale, and the values depend heavily on player count and view distance. Setting it too tight throws out your own players, starting with the ones on the worst connections.

Plain iptables rules are gone after a reboot. On Debian and Ubuntu you persist them like this:

apt-get install -y iptables-persistent
netfilter-persistent save

Under UFW such rules additionally belong in /etc/ufw/before.rules, because otherwise they disappear on the next ufw reload. Whether a rule is reached at all is shown by iptables -L INPUT -n -v: if the hit counters stay at zero, it is not taking effect.

7. Configure kernel connection tracking correctly

This point explains outages that look like a volumetric attack but are not one. The kernel creates connection tracking entries for UDP traffic, and with spoofed source addresses every address means a new entry. Once the table is full, the kernel drops packets without distinction, the attack and your players go out together, and the log says "nf_conntrack: table full". Current state and limit are shown by:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

For most games the best answer to this is to not track game traffic at all. With Hytale that is a real trade-off, because the 1200 byte rule from step 6 needs connection tracking. Without it the filter does not know which packet opens a new flow. The recommendation is therefore: keep tracking, enlarge the table, keep the UDP timeout short. A drop-in file under /etc/sysctl.d/, activated with sysctl --system:

net.netfilter.nf_conntrack_max = 1048576
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 120
net.core.rmem_max = 16777216
net.core.rmem_default = 1048576
net.core.netdev_max_backlog = 16384

If you want tracking off anyway, for instance on a machine with very many simultaneous players, put udp dport 5520 notrack in the raw table and give up the 1200 byte rule in exchange. You cannot have both. For a single Hytale server the rule is worth more than the saved table entries.

If packets arrive faster than the Java process picks them up, the receive buffer overflows on top of everything else. To the players that looks like packet loss even though the line is free. Whether the buffer settings above are needed is something the kernel tells you itself: if UdpRcvbufErrors in nstat -az climbs, they are doing something. If the counter stays at zero, the change makes no difference.

8. Match view distance and player count to your line

This step is not a security measure, but it decides how much attack you can absorb in the first place. Hypixel Studios put it plainly in the official hardware requirements of December 1, 2025: doubling the view distance quadruples the amount of world around the player. The official guidance is at most 12 chunks, that is 384 blocks, set through MaxViewRadius. On the client side the same requirements name 2 Mbit/s as the minimum and 8 Mbit/s as the recommendation per player for multiplayer.

Work that out for your own server once. A server with 40 players at a generous view distance moves a low three digit megabit figure in normal operation. That is the number your line has to be measured against, and it is at the same time the number an attack has to exceed to stand out. Anyone filling a third of a 1 Gbit/s line in normal operation has less headroom than someone sitting at five percent. A smaller view distance is therefore not only a performance question but also a question of robustness.

9. Keep an eye on mods, plugins and protocol changes

Hytale is moddable on the server side: mods sit as .zip or .jar in the mods/ directory, and plugins address the server interface directly. That is convenient, because players do not have to install anything, and at the same time it is an availability risk that has nothing to do with attacks. A plugin that does expensive work per network event is an amplifier inside your own house.

On top of that comes the protocol change. With Update 6 the network protocol changed from hytale/2 to hytale/3 according to the official patch notes of August 27, 2026, and servers and plugins need a rebuild before they will connect. For availability that means: keep a list of your mods including versions, test them on a second instance before every update, and schedule a maintenance window before October 12, 2026. A server that does not start after an update is indistinguishable from an attack as far as your players are concerned.

10. Collect measurements before things get serious

The most important step is the one almost nobody takes in advance: establish a baseline while everything is still normal. Without a normal value you cannot say after an incident whether 40,000 packets per second was a lot or simply Saturday night. With apt-get install -y vnstat sysstat conntrack the measurement runs continuously. During an incident five commands are enough:

sar -n DEV 1 10
ip -s link show eth0
conntrack -C
nstat -az | grep -i -E 'udp|drop'
tcpdump -ni eth0 -c 200 "udp port 5520"

With tcpdump one rule holds: always bound it with -c, a capture under full load puts extra strain on an already overloaded server. Because the Hytale server runs on Java, you need a second sample that rules out the most common false alarm. A garbage collection pause looks to players exactly like an attack: everybody freezes at the same moment, then it continues. The difference is in the numbers.

jcmd $(pgrep -f HytaleServer.jar) GC.heap_info
tail -n 200 logs/latest.log

Reading it is simple. If inbound packets climb far above your normal value while the Java process is barely working, it is an attack. If the packet rate stays unremarkable while the heap fills up or the log shows long pauses, it is load. How to evaluate the network figures in detail is covered in Detecting a DDoS attack on your server.

11. Backup, rollback plan and a rehearsal before the big date

A protection concept that was never tested is a guess. Before a date like October 12, 2026 four things belong done: a backup of the universe/ directory including config.json that lives off the machine, a verified way back to the previous server version, a second instance on which you apply the update first, and a one time load test that actually triggers your own filter rules.

The load test is where most operators stop, and it is the most important one. Do not test whether your rules block attacks, test whether they let your own players through. Watching the hit counters while twenty real players join at the same time is enough. If the counters of your drop rules climb during that, your limit is too tight, and you would have found out on update day under the worst possible conditions.

Where these measures end: bandwidth and packet rate

Now for the part no configuration file can solve. Every measure so far runs on your server, which means at the end of the line. A firewall rule decides about a packet that has already traveled down the cable. You can drop it, but you cannot unsend it.

Do the arithmetic once. A typical game server sits on 1 Gbit/s, which is 125 megabytes per second, and the line is full as soon as somebody sends more. Attacks against game server projects usually land between 5 and 50 Gbit/s, which is five to fifty times your line. Whether your nftables rule behind it is any good no longer matters, because your players' packets never get through in the first place.

The second figure is the packet rate, and it often bites earlier than bandwidth does. With small packets of 64 bytes, around 1.49 million packets per second fit into a 1 Gbit/s line. A normal server kernel processes a few hundred thousand of those, depending on processor and network card, before it starts dropping. An attack that does not even fill a third of your line can therefore still take your server down, because the CPU time goes into the dropping. Operators experience this as "utilization was not even high and everything was gone anyway".

With Hytale a third figure joins in that most games do not have: the CPU time of the connection setup. A flood of valid connection attempts from a botnet fills no line and produces no remarkable packet rate, it keeps the processor busy with cryptography. Such attacks are invisible in the bandwidth graph and obvious in the CPU load of the Java process, and neither a rate limit per source address nor a larger receive buffer helps against them once the sources are numerous enough.

For a sense of the magnitudes that actually occur: on KernelHost servers we have filtered, among others, an attack of more than 473.4 Gbit/s at more than 41.5 million packets per second against a voice server, and a UDP flood of more than 112.2 Gbit/s against a game server. There is no local setting for that. Volumetric attacks have to end in the network in front of the server.

What KernelHost puts up against DDoS attacks on Hytale servers

The always on protection included in every server package

DDoS protection at KernelHost is built in two stages and permanently active, without you having to enable, order or configure anything:

• Stage 1: 17 Tbps of mitigation capacity in the global scrubbing network. Volumetric attacks are cleaned close to their source, before they reach the datacenter.
• Stage 2: Arbor real time filtering with 3.2 Tbps in Frankfurt am Main. Directly in front of the server, protocol specific patterns are recognized and dropped, packet by packet.

Two properties are decisive. The protection runs permanently and does not have to react to an attack first, so there are no opening minutes in which the server is gone. And no null routing is used: your IP address stays in the network, only the malicious packets are dropped. Taking an IP address out of the network achieves the same result for you as the attacker does. Which titles and protocols are covered by dedicated protection profiles is listed in Real time DDoS protection for game servers.

Advanced DDoS Protection for Hytale projects under sustained fire

Some projects are not attacked occasionally but deliberately and for weeks, and with a game in Early Access that hits the servers which are currently growing hardest. For those there is Advanced DDoS Protection from €50.00 per month, PrePaid, with no minimum term and no setup fee. The difference is not more capacity, it is control:

• A dedicated protected IP from the Frankfurt core, onto which your server is moved inside our own network. Nothing has to be rebuilt on your side.
• Self managed protection rules per port and protocol in the customer panel: you define what is allowed on 5520 UDP, separately from everything else, and you need no ticket for it.
• Changes take effect in real time, so you can tune while an attack is running, for example by limiting new connections harder for a while and leaving ongoing game traffic untouched.
• A rule set that fits the protocol, for QUIC over UDP just as much as for your own applications on any TCP or UDP port.

Advanced DDoS Protection is intended for servers hosted at KernelHost. If you currently run your Hytale project elsewhere and are attacked continuously, moving it to KernelHost is the way to get it, and both stages then apply from provisioning onwards.

The two stages compared

For most Hytale servers the included always on protection together with a clean server configuration is enough. Advanced DDoS Protection is the answer to somebody taking it personally.

What transfers from other games to Hytale

Because Hytale is still young and there are no public figures on attacks against Hytale servers, the fastest route to reliable knowledge is to look at comparable games. What transfers is not the port number, it is the pattern.

• The explosive launch and what it triggers: Palworld shows how a wave of new players and a wave of attacks overlap in time, and why growing servers in particular become targets.
• The difference between query and game traffic: Minecraft Bedrock explains amplification over UDP through the unconnected ping. That is exactly the attack path Hytale does not have thanks to QUIC, and it is the clearest way to understand the difference.
• Connection setup as a target: Minecraft DDoS protection and nullping protection describes handshake floods that get by on almost no bandwidth. That is the nearest relative of the QUIC connection flood.
• Small player counts and slot exhaustion: Project Zomboid and Conan Exiles show how little effort it takes to lock out a fixed group, and what role a whitelist and a password play in that.
• Running under sustained load: Terraria shows how a single server process with single core load reacts to attacks. The Hytale server is a Java process, and the underlying problem is comparable.

Common mistakes on Hytale servers and how to fix them

"I opened port 5520 TCP and players still cannot get in": Game traffic runs over QUIC, which means over UDP. A TCP rule does nothing for game traffic. Open 5520 UDP and verify it from outside with nmap -Pn -sU -p 5520. If you moved the server to a different port with --bind, the rule has to name that port.

"The server is running but nobody can join, and the log says nothing about attacks": Check the server's sign in to its account with /auth status. A server whose sign in has expired keeps running and turns players away regardless. That is neither a network problem nor a filter rule.

"Nothing starts after the update": That is not an attack, it is the protocol change. With Update 6 the network protocol changed from hytale/2 to hytale/3, and servers as well as plugins need a rebuild. Apply updates on a second instance first, before you let them near the production server.

"Every player freezes for two seconds at the same time, then it continues": That is in all likelihood the Java runtime's garbage collection and not an attack. Check jcmd ... GC.heap_info and the server log. If sar -n DEV 1 10 stays unremarkable during it, no attack was involved, only a heap that is too small or a view distance that is too large.

"My rule against small packets locked out my players": Then the 1200 byte condition is in the chain without ct state new. Ongoing game traffic consists mostly of small packets, and a length condition without a state check hits exactly those. The condition applies to newly opened flows only.

"I changed the IP address and was offline again two hours later": The attacker got the new address from the same place as the old one. With Hytale that is usually an outdated A record in DNS, a Discord bot with a status display, or an entry in one of the many third party server lists. Since Update 6 server addresses are hidden by default in the official server list, which closes the most convenient route but not all of them. Changing addresses buys time, it does not solve anything.

"My filter rules are not taking effect": Three causes are common. The rules sit behind the UFW chains and are never reached, they were gone after the last reboot (in which case netfilter-persistent save or an entry in /etc/ufw/before.rules helps), or the attack is volumetric and the rule is working correctly on a line that is already full. Check with iptables -L INPUT -n -v whether the hit counters are climbing.

"My previous provider blocked my IP address": That is null routing. The provider is protecting its own network with it, and for you the result is identical to a successful attack, usually for hours afterwards as well. When in doubt, ask whether traffic is filtered or null routed. That answer tells you more about your availability than any hardware specification.

"I see nothing unusual in tcpdump": If the traffic is already filtered in the network in front of you, then as expected nothing arrives on the server. That is the normal case with working filtering. The reverse also holds: if the line is saturated, even the SSH session you wanted to measure with may not reach you. Use the VNC console in the customer panel in that case, which works independently of the guest system's network.

In short

• A Hytale server needs exactly one open port: 5520 UDP for QUIC. TCP is not required for game traffic, and the public documentation describes no further port for queries, RCON or remote control.
• Because QUIC per RFC 9000 must not send more than three times the received bytes before address validation, and because a first connection attempt has to be at least 1200 bytes, a Hytale server is practically worthless as a reflection amplifier. That sets it apart from servers with a Steam query or a Bedrock unconnected ping.
• That same 1200 byte rule is the best local filter rule: anything that wants to open a new flow on 5520 UDP and is smaller cannot be a valid connection setup, and it can be dropped without touching connected players.
• The expensive part of a QUIC handshake is the cryptography, not the bandwidth. A flood of valid connection attempts is invisible in the bandwidth graph and shows up only in the CPU load and in the counters for new connections.
• The default mode with its account requirement is an access filter that makes bulk accounts expensive. On a public server it stays untouched, joined by whitelist.json, bans.json and a value set in Password against slot exhaustion.
• Local measures end at the line: 1 Gbit/s is 125 megabytes per second, and at 64 byte packets around 1.49 million packets per second fit into it. Everything above that has to end in the network in front of the server.
• Hytale has been in Early Access since January 13, 2026, and Chapter 1 is announced for October 12, 2026. Big dates are attack dates, and protection ordered on the date itself arrives too late.
• At KernelHost the two stage always on protection is included in every server package at no extra cost and active from provisioning onwards, with no null routing. Advanced DDoS Protection with a dedicated protected IP and self managed rules per port starts at €50.00 per month.

If your Hytale server already runs at KernelHost, the filtering is active without you having to do anything. If you notice something unusual anyway, open a support ticket so that the filter rules for your IP address get tuned. While an attack is running you can also reach us through the WhatsApp emergency chat at +43 650 8209883.

This article reflects the state of September 27, 2026. Hytale is in Early Access, and the network protocol has already changed once this year. It will be updated after Chapter 1 and after every update that touches the connection setup, the ports or the server list.