Skydda Hytale-servern mot DDoS-attacker

En Hytale-server som på kvällen mitt i spelet tappar alla anslutningar samtidigt, är onåbar i ett par minuter och sedan går av sig själv igen har sällan ett hårdvaruproblem. I regel pågår en attack. Det här inlägget visar hur du skyddar en Hytale-server mot DDoS-attacker: först det som du kan konfigurera själv utan extra kostnader, sedan stället där de åtgärderna tar slut rent tekniskt, och till sist vad som måste hända i nätet framför servern för att servern ska förbli nåbar.

Alla uppgifter avser den officiella dedikerade servern från Hypixel Studios, alltså HytaleServer.jar tillsammans med Assets.zip under Java 25, driven på Debian 12, Debian 13, Ubuntu 22.04 LTS eller Ubuntu 24.04 LTS. Kommandona är skrivna för root, som vanlig användare sätter du sudo framför. Hytale är i Early Access och rör sig snabbt: därför bär varje utsaga om spelet i det här inlägget ett datum, och allt som inte är officiellt belagt är uttryckligen märkt som förväntan eller som community-källa. Om attacken pågår just nu gäller dessutom en ordning: mät först, ändra sedan. En hård omstart under last förkastar allt som har hänt i världen sedan den senaste sparpunkten, och incidentens mätvärden är därefter också borta.

Varför Hytale-servrar lamslås målmedvetet med DDoS-attacker

En Hytale-server är en publik på en fast adress, och den publiken är utbytbar. Den som tre kvällar i rad inte kommer in på sin stamserver letar upp en annan. Exakt det är affärsmodellen bakom attacker på community-servrar: det handlar inte om data och inte om utpressning, utan om spelare som drar vidare. En booter-tjänst som beskjuter en adress för ett par euro i månaden kräver av uppdragsgivaren varken kunnande eller arbete, och skadan uppstår på nytt vid varje avbrott.

Till det kommer hos Hytale en särskild omständighet: serverkoden är offentlig. Hypixel Studios har i juni 2026 tillkännagett programmet Hytale Shared Source och ställer via det den fullständiga serverkoden, nätverksprotokollet och assets till förfogande över GitHub, tillgängligt för alla med giltig spellicens. För dem som driver servrar är det en vinst, eftersom plugins uppstår mot riktiga gränssnitt. För attacksidan betyder det att ingen längre behöver gissa protokollet. Den som vill veta på vilket ställe uppkopplingen kostar processortid kan läsa sig till det. Vad som tekniskt sker vid en sådan attack förklarar inlägget Vad är en DDoS-attack?.

Läget kring Hytale den 27 september 2026

Hytale är sedan den 13 januari 2026 i Early Access, tillgängligt för Windows, macOS och Linux, och har under dagarna efter starten nått över en miljon spelare. Vägen dit var ovanlig, och den förklarar varför äldre artiklar om Hytale ofta inte stämmer längre.

Den praktiska följden av den kronologin: en Hytale-server av i dag är ingen server från januari. Med Update 6 har nätverksprotokollet ändrats från hytale/2 till hytale/3, och enligt de officiella Patch Notes från den 27 augusti 2026 måste server och plugins byggas om innan de ansluter. Den som planerar sin tillgänglighet planerar därför inte bara mot attacker, utan också mot protokollbyten.

Varför den 12 oktober 2026 är det kritiska datumet

Stora innehållsuppdateringar verkar som en andra försäljningsstart. De tar tillbaka gamla spelare, drar till sig nya, och under ett par dagar avgör nåbarheten vilken community-server som växer ur den vågen och vilken som missar den. Det mönstret är belagt hos andra spel: Palworld nådde i januari 2024 miljoner spelare inom ett par dagar, och den startfasens community-servrar var mest attackerade i exakt det ögonblick då de hade mest att förlora. Mekaniken bakom det är utförligt beskriven i Skydda Palworld-servrar mot DDoS-attacker och går att överföra ett till ett på Hytale.

Därav följer en obekväm sanning om tidsplanen: skydd som beställs den 12 oktober är för sent. En ledning, en skydds-IP, ett regelverk per port och ett mätvärde för normal drift behöver framförhållning, eftersom de inte går att ställa in vettigt utan jämförelsedata. Den som börjar två veckor före en stor uppdatering har tid nog. Den som börjar på uppdateringens dag justerar i blindo.

Portarna som det faktiskt handlar om hos en Hytale-server

En Hytale-server behöver exakt en öppen port: 5520 UDP. Speltrafiken går över QUIC, alltså över UDP, och TCP behövs inte för speltrafiken. Den som bara släpper fram TCP ser samma bild som vid en stängd brandvägg: spelarna löper in i en tidsgräns. Standardbindningen lyder 0.0.0.0:5520, en annan port sätts vid start med --bind.

Den tabellen är kortare än hos de flesta andra spel, och det är den viktigaste skillnaden. En Counter-Strike-server besvarar statusförfrågningar i Steam-formatet A2S, en Minecraft Bedrock-server svarar på en Unconnected Ping, en Palworld-server håller en egen query-port öppen. För Hytale är i den offentliga dokumentationen ingen ytterligare port beskriven vid sidan av 5520 UDP: ingen query-port, ingen RCON-port, inget REST-gränssnitt i leveranstillståndet. Allt som en Hytale-server erbjuder utåt ligger på en enda UDP-port.

Hytale-servern i siffror

Följande värden är grunden för varje beslut om filterregler och gränsvärden. Härkomsten står varje gång med, eftersom den avgör hur mycket värdet bär.

Vad QUIC ändrar på attackytan

QUIC är ett transportprotokoll som upprättar säkrade anslutningar över UDP och har krypteringsuppbyggnaden enligt TLS 1.3 fast inbyggd. Det finns inget okrypterat QUIC. För den som driver en server betyder det två saker som motsäger varandra, och båda är viktiga.

Den första är en verklig förbättring. Eftersom UDP inte tvingar fram någon uppkoppling och avsändaradresser går att förfalska är anslutningslösa UDP-tjänster de klassiska förstärkarna för attacker mot tredje part. QUIC begränsar det i standarden. RFC 9000 föreskriver i avsnitt 8.1 att en server före kontrollen av avsändaradressen får skicka högst tre gånger mängden mottagna byte, och avsnitt 14.1 kräver att en klient fyller ut sitt första datagram till minst 1 200 byte. Tillsammans lyfter de båda reglerna förstärkningsfaktorn hos en QUIC-tjänst till maximalt tre, medan en Steam-query-port eller en Bedrock-Unconnected-Ping kommer upp i en multipel av det. En korrekt arbetande Hytale-server är därför praktiskt ointressant som reflektionsförstärkare. Det är en strukturell fördel mot nästan alla andra spel med UDP-trafik, och vid jämförelsen med Minecraft Bedrock-servrar faller den tydligt ut.

Den andra är priset för det. En QUIC-uppkoppling kostar servern processortid, för den omfattar en TLS-1.3-förhandling med asymmetrisk kryptografi. Ett enstaka förfalskat paket kan inte tvinga fram någon uppkoppling, men en flod av äkta anslutningsförsök ur ett botnät kan. Angriparen betalar därvid också processortid, och exakt det förhållandet avgör: så länge servern utför mer arbete per anslutningsförsök än angriparen är attacken ekonomisk. En flod av anslutningsförsök belastar därför inte ledningen, utan processorn, och den ser i bandbreddsstatistiken ut som ingenting. Det är samma mekanism som hos Minecraft är känd som nullping och handskakningsflod och som beskrivs i detalj i inlägget DDoS-skydd och nullping-skydd för Minecraft.

Praktiskt användbart är av det framför allt regeln om 1 200 byte. Ett nytt anslutningsförsök måste komma in som ett datagram på minst 1 200 byte, annars är det enligt standarden ingen giltig uppkoppling. Löpande speltrafik består däremot till övervägande del av små paket. Den åtskillnaden går att gjuta i en filterregel, och till det kommer vi strax.

Vad som inte är offentligt dokumenterat om Hytale

Den listan hör hemma i en ärlig artikel, eftersom den fastställer var du inte får förlita dig på siffror. Allt det följande är per den 27 september 2026 inte officiellt belagt:

• Om servern använder QUIC-Retry till adresskontroll. RFC 9000 tillåter i avsnitt 8.1.2 ett Retry-paket med token, med vilket en server kontrollerar avsändaradressen innan den binder resurser. Om och från vilken last Hytale gör det är inte dokumenterat. Antag att du inte kan förlita dig på det.
• Förvalda värden i blocken RateLimit och ConnectionTimeouts i config.json. Att de båda blocken finns är konsistent över flera källor. De nämnda siffrorna motsäger dock varandra: en källa nämner konkreta gränsvärden, en annan beskriver blocken som befintliga men utan verkan. Därför står ingen av de siffrorna i det här inlägget, och därför bör du inte planera in de blocken som ditt försvar.
• Namnen på och förvalen för autentiseringslägena. Community-dokumentationen till den offentliggjorda serverkoden beskriver tre lägen, satta via --auth-mode, med authenticated som förval samt offline och insecure för privata miljöer och utveckling. Officiellt bekräftat är det inte. Regeln som följer därav är trots det entydig: ändra inte läget för en offentlig server.
• Detaljer i TLS-uppbyggnaden. Community-protokolldokumentationen, som vilar på den offentliggjorda serverkoden, beskriver ett certifikat i båda riktningarna, ett självutfärdat servercertifikat som skapas vid start och vars SHA-256-fingeravtryck når klienterna via sessionstjänsten, samt ett avstängt 0-RTT. Det är rimligt och passar till TLS 1.3, men är inte officiellt bekräftat, och det ändrar ingenting i åtgärderna längre ner.
• Attackstorlekar speciellt mot Hytale-servrar. Det finns inga offentliga siffror om det. De 5 till 50 Gbit/s som nämns i tabellen är ett erfarenhetsvärde över spelserverprojekt i allmänhet och uttryckligen ingen Hytale-statistik.
• Paketfrekvenser i normal drift per spelare. Även för det finns ingen publikation som bär. Därför står i det här inlägget inget gränsvärde som du skulle kunna överta oprövat, utan en anvisning om hur du mäter det själv.

Vad du kan göra själv innan du lägger pengar på saken

Följande steg stoppar ingen volymetrisk attack, det klarar ingen programvara på servern. De röjer däremot undan allt som ligger under det: portskanningar, floder av anslutningsförsök ur få källor, övertagningsförsök via administrationsgränssnitt som du har installerat därtill och att alla platser upptas av främlingar. Det är den största delen av det som stör en Hytale-server i vardagen, och det kostar en dryg timme.

1. Inventering: vad lyssnar på servern?

Innan du skriver en enda regel tittar du efter vad din server erbjuder utåt. Inte gissa, titta efter:

ss -lntup

Intressant är kolumnen med den lokala adressen. 0.0.0.0:5520 betyder "nåbar från hela internet", 127.0.0.1:8080 betyder "bara lokalt" och behöver ingen öppning. Vid sidan av serverns Java-process dyker på en maskin som har vuxit ofta en administrationspanel, en webbserver för kartvisningen och en databas upp. Angriparens vy ger en portskanning utifrån:

nmap -Pn -sU -p 5520 DIN.SERVER.IP.ADRESS
nmap -Pn -p- --min-rate 1000 DIN.SERVER.IP.ADRESS

Det andra anropet är det viktigare. Det visar vad som annars står öppet, och i praktiken är det nästan alltid mer än väntat.

2. Lämna bara 5520 UDP öppen, stäng allt annat

Två öppningar räcker. Med UFW ser det ut så här, och i exakt den ordningen, så att du inte låser ute dig själv:

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

En TCP-öppning på 5520 behöver du inte. Om du driver servern på en avvikande port måste öppningen passa till värdet ur --bind, annars går starten igenom och spelarna kommer ändå inte fram. Den fullständiga anvisningen jämte räddningsväg står i Sätt upp UFW-brandväggen utan att låsa ute dig själv.

För allt som du har installerat därtill för administrationen gäller samma regel som hos varje annat spel: inte ut i det öppna nätet, utan gör det nåbart via en SSH-vidarebefordran och arbeta därefter lokalt mot 127.0.0.1:

ssh -N -L 8080:127.0.0.1:8080 root@DIN.SERVER.IP.ADRESS

3. Starta servern så som den är tänkt

Starten består av ett enda kommando. Serverfilerna hämtar du via den officiella Hytale-nedladdaren eller ur din egen spelinstallation:

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

Vid första starten lägger servern upp config.json, katalogen logs/ och världskatalogen universe/. Därefter loggar du in den en gång på dess konto, så att autentiseringen av spelarna fungerar. Det går via en enhetskod i serverkonsolen:

/auth login device
/auth status

Sätt inte -Xmx till maskinens hela arbetsminne. Operativsystemet, filsystemcachen och Java-körtidens omkostnader utanför heapen behöver också plats, och en server som under last går in i växlingsutrymmet ser för dina spelare ut exakt som en attack.

4. Vitlista, serverlösenord och övre spelargräns mot slotutmattning

Slotutmattning är den billigaste attacken mot en community-server och behöver ingen bandbredd. Den som bygger upp tillräckligt många samtidiga anslutningar upptar alla platser och spärrar därmed ute den egentliga gemenskapen, utan att köpa en enda gigabit. Hytale har för det till skillnad från mången annan titel de passande verktygen i leveranstillståndet: en vitlista i whitelist.json, en spärrlista i bans.json, rättigheter i permissions.json och i config.json nycklarna Password och MaxPlayers.

{
  "ServerName": "Min Hytale-server",
  "MOTD": "",
  "Password": "ett värde som bara din grupp känner",
  "MaxPlayers": 40,
  "MaxViewRadius": 12
}

Password är tomt från fabrik, alla med adress och port kommer alltså in. För en sluten server är ett satt lösenord den verksammaste enskilda åtgärden mot slotutmattning, för en offentlig server är det vitlistan under en attackvåg. Och en sak måste vara klar: ett serverlösenord skyddar dina platser, inte din ledning. En angripare som översvämmar din server vill inte alls gå med.

Redigera de filerna bara vid stoppad server. Den löpande serverprocessen håller sin egen bild i minnet och kan vid nedstängning kommentarslöst skriva över ändringar som du under tiden skriver in i filen. För ändringar i löpande drift använder du konsolkommandona i stället för editorn.

5. Lämna autentiseringen på standardvärdet

Standardläget kräver av varje spelare ett giltigt Hytale-konto. Det är mer än en licenskontroll: det är ett åtkomstfilter som gör masskonton dyra. En angripare som vill uppta platser behöver giltiga konton för det, och de kostar pengar. Ta inte bort det filtret.

Community-dokumentationen beskriver vid sidan av standarden två ytterligare lägen för privata miljöer och för utveckling, med vilka man kan gå med utan kontokontroll. För en offentlig server är de den sämsta inställning som går att uppnå, eftersom de gör slotutmattningen från en pengafråga till en skriptfråga. Om du växlar om för att testa, gör det då på en maskin som inte står i internet, och växla tillbaka efteråt.

6. Begränsa nya anslutningsförsök, och det med regeln om 1 200 byte

Nu blir QUIC:s strukturella fördel praktisk. En giltig uppkoppling kommer enligt RFC 9000 in som ett datagram på minst 1 200 byte. Löpande speltrafik är betydligt mindre. Med anslutningsspårning kan du därför skilja nya dataströmmar från befintliga och förkasta allt som är nytt och för litet. Med nftables, laddat via 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
    }
}

Den första regeln arbetar på UDP-längden, alltså 8 byte huvud plus 1 200 byte nyttolast, tillsammans 1 208. Den träffar uteslutande paket som vill öppna en ny dataström och är för små för det, och den kan inte träffa anslutna spelare. Den andra regeln begränsar hur många nya anslutningar en enskild källadress får öppna per sekund. Fem per sekund är generöst: en riktig spelare bygger upp en anslutning och behåller den. Prioriteten -10 sörjer för att båda reglerna biter före UFW:s filterkedja.

En övre gräns för paketfrekvensen per källadress på spelporten själv är den tredje vettiga regeln, och här gäller uttryckligen: siffervärdet är ett startvärde, ingen sanning.

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

Mät först en vecka i normal drift, sätt sedan gränsen till det dubbla av det uppmätta toppvärdet. För Hytale finns inget publicerat referenstal för det, och värdena hänger starkt på spelarantal och siktvidd. Den som ställer för snävt kastar ut sina egna spelare, och då först och främst dem med den sämsta ledningen.

Rena iptables-regler är borta efter en omstart. Under Debian och Ubuntu säkrar du dem så här:

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

Under UFW hör sådana regler dessutom i /etc/ufw/before.rules, eftersom de annars försvinner vid nästa ufw reload. Om en regel överhuvudtaget nås visar iptables -L INPUT -n -v: står träffräknarna kvar på noll biter den inte.

7. Ställ in kärnans anslutningsspårning rätt

Den punkten förklarar avbrott som ser ut som en volymattack men inte är någon. Kärnan lägger upp poster i anslutningsspårningen för UDP-trafik, och vid förfalskade avsändaradresser betyder varje adress en ny post. Är tabellen full förkastar kärnan paket utan åtskillnad, attacken och dina spelare åker ut tillsammans, och i loggen står "nf_conntrack: table full". Läge och övre gräns visar:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

Hos de flesta spel är det bästa svaret på det att inte låta speltrafiken spåras alls. Hos Hytale är det en verklig avvägning, för regeln om 1 200 byte ur steg 6 behöver anslutningsspårningen. Utan den vet filtret inte vilket paket som öppnar en ny dataström. Rekommendationen lyder därför: behåll spårningen, förstora tabellen, håll tidsgränsen för UDP kort. Ett tillägg under /etc/sysctl.d/, aktiverat med 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

Den som trots det vill stänga av spårningen, till exempel på en maskin med mycket många samtidiga spelare, sätter udp dport 5520 notrack i tabellen raw och avstår därmed från regeln om 1 200 byte. Båda tillsammans går inte. För en enskild Hytale-server är regeln värd mer än de sparade tabellposterna.

Kommer paketen in snabbare än Java-processen hämtar dem svämmar dessutom mottagningsbufferten över. För spelarna ser det ut som paketförlust, trots att ledningen är ledig. Om buffertinställningarna ovan behövs avslöjar kärnan själv: stiger UdpRcvbufErrors i nstat -az så biter de. Står räknaren kvar på noll ändrar anpassningen ingenting.

8. Välj siktvidd och spelarantal så att de passar ledningen

Det steget är ingen säkerhetsåtgärd, men det avgör hur mycket attack du överhuvudtaget tål. Hypixel Studios har formulerat det klart i de officiella hårdvarukraven från den 1 december 2025: fördubblar du siktvidden fyrdubblar du mängden värld runt spelaren. Den officiella rekommendationen ligger vid högst 12 chunks, alltså 384 block, satt via MaxViewRadius. På klientsidan nämner samma krav 2 Mbit/s som minimum och 8 Mbit/s som rekommendation per spelare för flerspelarspelet.

Räkna igenom det en gång för din server. En server med 40 spelare vid generös siktvidd rör i normal drift ett lågt tresiffrigt megabit-område. Det är värdet som din ledning måste mätas mot, och det är samtidigt värdet som en attack måste överskrida för att falla i ögonen. Den som fyller en ledning med 1 Gbit/s till en tredjedel i normal drift har mindre reserv än någon som ligger på fem procent. En mindre siktvidd är därför inte bara en prestandafråga, utan också en fråga om robusthet.

9. Håll ett öga på mods, plugins och protokollbyten

Hytale går att modda på serversidan: mods ligger som .zip eller .jar i katalogen mods/, och plugins talar direkt med servergränssnittet. Det är bekvämt, eftersom spelarna inte behöver installera något, och det är samtidigt en tillgänglighetsrisk som inte har med attacker att göra. Ett plugin som arbetar dyrt per nätverkshändelse är en förstärkare i ditt eget hus.

Till det kommer protokollbytet. Med Update 6 har nätverksprotokollet enligt de officiella Patch Notes från den 27 augusti 2026 ändrats från hytale/2 till hytale/3, och server och plugins måste byggas om innan de ansluter. För tillgängligheten betyder det: för en lista över dina mods jämte version, pröva dem före varje uppdatering på en andra instans, och planera in ett underhållsfönster före den 12 oktober 2026. En server som inte startar efter en uppdatering går för dina spelare inte att skilja från en attack.

10. Samla mätvärden innan det blir allvar

Det viktigaste steget är det som nästan ingen tar i förväg: att lägga upp en jämförelsegrund så länge allt går normalt. Utan normalvärde kan du efter en incident inte säga om 40 000 paket per sekund var mycket eller helt enkelt lördagskväll. Med apt-get install -y vnstat sysstat conntrack går mätningen varaktigt i bakgrunden. Under en incident räcker fem kommandon:

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"

För tcpdump gäller: begränsa alltid med -c, en inspelning under full last belastar en redan överbelastad server ytterligare. Eftersom Hytale-servern går på Java behöver du en andra prövning som utesluter det vanligaste falska larmet. En paus i skräpsamlingen (garbage collection) ser för spelarna ut precis som en attack: alla står samtidigt, sedan går det vidare. Skillnaden står i siffrorna.

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

Utvärderingen är enkel. Stiger de inkommande paketen vida över normalvärdet medan Java-processen knappt arbetar är det en attack. Förblir paketfrekvensen oanmärkningsvärd medan heapen löper full eller loggen visar långa pauser är det last. Hur du utvärderar nätverksvärdena i detalj står i Känn igen en DDoS-attack på servern.

11. Backup, reservplan och en provkörning före det stora datumet

Ett skyddskoncept som aldrig har prövats är en förmodan. Före ett datum som den 12 oktober 2026 hör fyra saker undanstökade: en backup av katalogen universe/ jämte config.json som ligger utanför maskinen, en prövad återgång till den föregående serverversionen, en andra instans där du spelar in uppdateringen först, och ett engångs belastningstest som utlöser dina egna filterregler.

Belastningstestet är den punkt där de flesta som driver servrar slutar, och det är den viktigaste. Pröva inte om dina regler avvärjer attacker, utan om de släpper igenom dina egna spelare. För det räcker det att betrakta träffräknarna medan tjugo riktiga spelare går med samtidigt. Stiger räknarna för förkastningsreglerna därvid är din gräns satt för snävt, och du hade fått veta det på uppdateringens dag under de sämsta möjliga förhållandena.

Var de här åtgärderna tar slut: bandbredd och paketfrekvens

Nu den del som ingen konfigurationsfil kan lösa. Alla åtgärder hittills går på din server, alltså i änden av ledningen. En brandväggsregel avgör vad som händer med ett paket som redan har gått genom kabeln. Du kan förkasta det, men inte göra det oskickat.

Räkna på det en gång. En typisk spelserver hänger på 1 Gbit/s, det motsvarar 125 megabyte per sekund, och ledningen är full så snart någon skickar mer. Attacker mot spelserverprojekt ligger vanligen mellan 5 och 50 Gbit/s, alltså vid fem till femtio gånger din ledning. Om din nftables-regel bakom den är god spelar då ingen roll längre, för dina spelares paket kommer inte fram redan dessförinnan.

Den andra storheten är paketfrekvensen, och den slår ofta till tidigare än bandbredden. Vid små paket på 64 byte får runt 1,49 miljoner paket per sekund plats i en ledning med 1 Gbit/s. En vanlig serverkärna bearbetar beroende på processor och nätverkskort några hundratusen av dem innan den börjar förkasta. En attack som inte ens fyller din ledning till en tredjedel kan alltså ändå lamslå din server, eftersom processortiden går åt till att förkasta. De som driver servrar upplever det som "belastningen var ju inte alls hög, ändå var allt borta".

Hos Hytale tillkommer en tredje storhet som inte finns hos de flesta spel: processortiden för uppkopplingen. En flod av giltiga anslutningsförsök ur ett botnät fyller ingen ledning och skapar ingen anmärkningsvärd paketfrekvens, den håller processorn sysselsatt med kryptografi. Sådana attacker är osynliga i bandbreddsstatistiken och tydliga i Java-processens processorlast, och varken en hastighetsbegränsning per källadress eller en större mottagningsbuffert hjälper mot det, när källorna är tillräckligt talrika.

För att sätta in vilka storleksordningar som verkligen förekommer: på KernelHost-servrar har bland annat en attack med över 473,4 Gbit/s vid över 41,5 miljoner paket per sekund mot en röstserver och en UDP-flood med över 112,2 Gbit/s mot en spelserver filtrerats. För det finns ingen lokal inställning. Volymetriska attacker måste sluta i nätet framför servern.

Vad KernelHost ställer mot DDoS-attacker på Hytale-servrar

Det permanenta skyddet som ingår i varje serverpaket

KernelHosts DDoS-skydd är uppbyggt i två steg och permanent aktivt, utan att du måste slå på, beställa eller konfigurera något:

• Steg 1: 17 Tbps mitigeringskapacitet i det globala scrubbing-nätverket. Volymetriska attacker rensas nära sin källa innan de når datacentret.
• Steg 2: Arbor-realtidsfiltrering med 3,2 Tbps i Frankfurt am Main. Direkt framför servern känns protokollspecifika mönster igen och förkastas, paket för paket.

Två egenskaper är avgörande. Skyddet går permanent och behöver inte först reagera på en attack, det finns alltså inga minuter i början då servern är borta. Och ingen null-routning används: din IP-adress blir kvar i nätet, bara de skadliga paketen förkastas. Den som tar IP-adressen ur nätet uppnår för dig samma resultat som angriparen. Vilka titlar och protokoll som täcks med egna skyddsprofiler listar DDoS-skydd för spelservrar i realtid.

Advanced DDoS Protection för Hytale-projekt under ständig beskjutning

Vissa projekt attackeras inte tillfälligt, utan riktat och under veckor, och hos ett spel i Early Access träffar det särskilt de servrar som just växer. För det finns Advanced DDoS Protection från 50,00 € i månaden, PrePaid, utan bindningstid och utan uppläggningsavgift. Skillnaden ligger inte i mer kapacitet, utan i kontrollen:

• Dedikerad skydds-IP ur Frankfurt-kärnan, som din server ställs om till inom det egna nätet. På din sida behövs ingen ombyggnad.
• Skyddsregler per port och protokoll som du hanterar själv i kundportalen: du fastställer vad som tillåts på 5520 UDP, skilt från allt annat, och behöver inget ärende för det.
• Ändringar träder i kraft i realtid, du kan alltså justera under en pågående attack, till exempel begränsa nya anslutningar hårdare en kort tid och lämna den löpande speltrafiken oberörd.
• Regelverk passande till protokollet, för QUIC över UDP lika väl som för egna applikationer på valfria TCP- eller UDP-portar.

Advanced DDoS Protection riktar sig till servrar som står hos KernelHost. Den som för närvarande driver sitt Hytale-projekt någon annanstans och attackeras varaktigt flyttar det till KernelHost, då biter båda stegen från leveransen.

De båda stegen jämförda

För de flesta Hytale-servrar räcker det inkluderade permanenta skyddet tillsammans med en ren serverkonfiguration. Advanced DDoS Protection är svaret på att någon tar det personligt.

Vad som går att överföra från andra spel på Hytale

Eftersom Hytale ännu är ungt och det inte finns några offentliga siffror om attacker mot Hytale-servrar är den snabbaste vägen till kunskap som bär en blick på jämförbara spel. Överförbar är därvid inte portnumret, utan mönstret.

• Den explosiva starten och vad den utlöser: Palworld visar hur en våg av nya spelare och en våg av attacker överlagrar varandra i tid och varför just växande servrar blir mål.
• Skillnaden mellan förfrågan och speltrafik: Minecraft Bedrock förklarar via Unconnected Ping hur förstärkning över UDP fungerar. Exakt den attackvägen har Hytale inte tack vare QUIC, och där går skillnaden bäst att förstå.
• Uppkopplingen som attackmål: DDoS-skydd och nullping-skydd för Minecraft beskriver handskakningsfloder som klarar sig med nästan ingen bandbredd. Det är den närmaste släktingen till QUIC-anslutningsflooden.
• Små spelarantal och slotutmattning: Project Zomboid och Conan Exiles visar hur lite arbete som behövs för att spärra ute en fast grupp, och vilken roll vitlista och lösenord spelar i det.
• Drift under varaktig last: Terraria visar hur en enskild serverprocess med enkelkärnelast reagerar på attacker. Hytale-servern är en Java-process, grundproblemet är jämförbart.

Vanliga fel hos Hytale-servrar och deras lösning

"Jag släppte fram port 5520 TCP och spelarna kommer ändå inte in": Speltrafiken går över QUIC, alltså över UDP. En TCP-öppning ger ingenting för speltrafiken. Släpp fram 5520 UDP och pröva det utifrån med nmap -Pn -sU -p 5520. Om du har lagt servern på en annan port med --bind måste öppningen nämna den porten.

"Servern går, men ingen kan gå med, och i loggen står ingenting om attacker": Pröva serverns inloggning på dess konto med /auth status. En server vars inloggning har löpt ut går vidare och avvisar ändå spelare. Det är inget nätverksproblem och ingen filterregel.

"Efter uppdateringen startar ingenting längre": Det är ingen attack, utan protokollbytet. Med Update 6 har nätverksprotokollet ändrats från hytale/2 till hytale/3, och server såväl som plugins behöver ett nytt bygge. Spela in uppdateringar först på en andra instans innan du släpper dem på produktionsservern.

"Alla spelare står samtidigt i två sekunder, sedan går det vidare": Det är med hög sannolikhet Java-körtidens skräpsamling och ingen attack. Pröva jcmd ... GC.heap_info och serverloggen. Förblir sar -n DEV 1 10 därvid oanmärkningsvärd var ingen attack med i spelet, utan en för snålt tilltagen heap eller en för stor siktvidd.

"Min regel mot små paket har spärrat ute spelarna": Då står villkoret om 1 200 byte utan ct state new i kedjan. Löpande speltrafik består till övervägande del av små paket, och ett längdvillkor utan tillståndskontroll träffar exakt dem. Villkoret gäller uteslutande för nyöppnade dataströmmar.

"Jag bytte IP-adress och var offline igen två timmar senare": Angriparen har den nya adressen ur samma källa som den gamla. Hos Hytale är det oftast en gammal A-post i DNS, en Discord-bot med statusvisning eller en post i en av de många serverlistorna från tredje part. Sedan Update 6 är serveradresser i den officiella serverlistan dolda från fabrik, vilket stänger den bekvämaste vägen, men inte alla. Ett adressbyte är tidsvinst, ingen lösning.

"Mina filterregler biter inte": Tre orsaker är vanliga. Reglerna står bakom UFW-kedjorna och nås aldrig, de var borta efter den senaste omstarten (då hjälper netfilter-persistent save eller en post i /etc/ufw/before.rules), eller så är attacken volymetrisk och regeln arbetar korrekt vid en ledning som redan är full. Pröva med iptables -L INPUT -n -v om träffräknarna stiger.

"Min tidigare leverantör har spärrat min IP-adress": Det är null-routning. Leverantören skyddar därmed sitt eget nät, för dig är resultatet identiskt med en lyckad attack, oftast i timmar därefter. Fråga i tveksamma fall om det filtreras eller null-routas. Svaret avgör mer om din tillgänglighet än varje hårdvaruuppgift.

"I tcpdump ser jag inget anmärkningsvärt": Filtreras trafiken redan i nätet framför kommer som väntat ingenting fram på servern. Det är normalfallet vid fungerande filtrering. Omvänt gäller: är ledningen mättad når dig under vissa omständigheter inte ens SSH-sessionen som du ville mäta med. Använd då VNC-konsolen i kundportalen, som fungerar oberoende av gästsystemets nätverk.

Kort sammanfattat

• En Hytale-server behöver exakt en öppen port: 5520 UDP för QUIC. TCP behövs inte för speltrafiken, och i den offentliga dokumentationen är ingen ytterligare port beskriven för förfrågningar, RCON eller fjärrstyrning.
• Eftersom QUIC enligt RFC 9000 före adresskontrollen får skicka högst tre gånger den mottagna bytemängden och ett första anslutningsförsök måste vara minst 1 200 byte stort, är en Hytale-server praktiskt ointressant som reflektionsförstärkare. Det skiljer den från servrar med Steam-förfrågan eller Bedrock-Unconnected-Ping.
• Samma regel om 1 200 byte är den bästa lokala filterregeln: det som vill öppna en ny dataström på 5520 UDP och är mindre kan inte vara någon giltig uppkoppling och går att förkasta utan att träffa anslutna spelare.
• Den dyra delen av en QUIC-uppkoppling är kryptografin, inte bandbredden. En flod av giltiga anslutningsförsök är osynlig i bandbreddsstatistiken och syns bara i processorlasten och i räknarna för nya anslutningar.
• Standardläget med kontokrav är ett åtkomstfilter som gör masskonton dyra. För en offentlig server blir det oberört, till det kommer whitelist.json, bans.json och ett satt värde i Password mot slotutmattning.
• Lokala åtgärder slutar vid ledningen: 1 Gbit/s är 125 megabyte per sekund, och vid 64 byte stora paket får runt 1,49 miljoner paket per sekund plats där. Allt däröver måste sluta i nätet framför servern.
• Hytale är sedan den 13 januari 2026 i Early Access, Chapter 1 är aviserat till den 12 oktober 2026. Stora datum är attackdatum, och skydd som beställs på datumet kommer för sent.
• Hos KernelHost ingår det permanenta skyddet i två steg i varje serverpaket utan extra kostnad och är aktivt från leveransen, utan null-routning. Advanced DDoS Protection med dedikerad skydds-IP och regler per port som du hanterar själv börjar vid 50,00 € i månaden.

Går din Hytale-server redan hos KernelHost är filtreringen aktiv utan att du behöver göra något. Märker du ändå något anmärkningsvärt öppnar du ett supportärende, så att filterreglerna för din IP-adress justeras. Vid en pågående attack når du oss dessutom via WhatsApp-nödchatten på +43 650 8209883.

Det här inlägget har läget per den 27 september 2026. Hytale är i Early Access, och nätverksprotokollet har redan ändrats en gång under det här året. Det skrivs vidare efter Chapter 1 och efter varje uppdatering som berör uppkopplingen, portarna eller serverlistan.