保护 Hytale 服务器免受 DDoS 攻击

一台 Hytale 服务器如果在晚上玩到一半时所有连接同时断开，几分钟内无法访问，随后又自己恢复，那很少是硬件问题。绝大多数情况下正在发生一次攻击。本文讲的是如何保护 Hytale 服务器免受 DDoS 攻击：先讲您不花额外费用就能自己配置的部分，然后讲这些措施在技术上到哪里为止，最后讲服务器前面的网络里必须发生什么，服务器才能一直可达。

所有说明针对 Hypixel Studios 的官方独立服务器，也就是 HytaleServer.jar 连同 Assets.zip 在 Java 25 下运行，部署在 Debian 12、Debian 13、Ubuntu 22.04 LTS 或 Ubuntu 24.04 LTS 上。命令以 root 身份书写，普通用户请在前面加上 sudo。Hytale 处于 Early Access（抢先体验）阶段，变动很快：因此本文中每一句关于这款游戏的陈述都带日期，凡是没有官方依据的内容，都明确标注为预期或社区来源。如果攻击正在进行，还有一条顺序：先测量，再改动。带着负载做硬重启会丢掉世界里自上一个存档点以来发生的一切，而这次事件的测量数据之后同样也没了。

为什么 Hytale 服务器会被有针对性地用 DDoS 攻击打瘫

一台 Hytale 服务器是固定地址上的一群观众，而这群观众是可以替换的。晚上连着三次进不了自己常去的服务器，人就会去找别的。这正是攻击社区服务器背后的生意逻辑：目标不是数据，也不是勒索，而是那些会走掉的玩家。一个每月花几欧元就能打一个地址的 booter 服务，对委托方既不要求本事也不要求投入，而损失在每一次宕机中重新产生。

Hytale 这里还多一个特点：服务端代码是公开的。Hypixel Studios 在 2026 年 6 月宣布了 Hytale Shared Source 计划，并通过 GitHub 提供完整的服务端代码、网络协议和资源文件，凡持有有效游戏许可的人都可以访问。对服务器运营者来说这是好事，因为插件可以针对真实接口来写。而对攻击一方来说，这意味着协议再也不必去猜。想知道连接建立过程在哪一步要花计算时间的人，可以直接读出来。这样一次攻击在技术上发生了什么，请看文章 什么是 DDoS 攻击？。

Hytale 在 2026 年 9 月 27 日的状态

Hytale 自 2026 年 1 月 13 日起处于 Early Access 阶段，支持 Windows、macOS 和 Linux，并在上线后的几天内达到超过 100 万名玩家。走到这一步的过程很不寻常，而它也解释了为什么更早的 Hytale 文章往往已经不对了。

这条时间线的现实后果是：今天的 Hytale 服务器不是一月的那台服务器。随着 Update 6，网络协议从 hytale/2 变成了 hytale/3，而按 2026 年 8 月 27 日的官方更新说明，服务器和插件必须重新构建才能连上。因此谁要规划自己的可用性，就不只要针对攻击来规划，还要针对协议变更来规划。

为什么 2026 年 10 月 12 日是关键日期

大型内容更新的作用像第二次发售。它们把老玩家带回来，也吸引新玩家，而在那几天里，可达性决定了哪个社区服务器能从这波浪潮里长起来，哪个会错过它。这种模式在其他游戏上有据可查：Palworld（幻兽帕鲁）在 2024 年 1 月几天之内就达到数百万玩家，而那个起步阶段的社区服务器，恰恰是在它们损失最大的时候被攻击得最多。背后的机制在 保护 Palworld 服务器免受 DDoS 攻击中有详细描述，而且可以一对一套到 Hytale 上。

由此得出一条关于时间表的不中听的结论：10 月 12 日才下单的防护来得太晚。一条线路、一个防护 IP、一套按端口的规则集，以及一个正常运行状态下的测量值，都需要提前量，因为没有对照数据就没法合理地设定它们。在大更新前两周动手的人时间够用。在更新当天才动手的人，是在盲飞状态下调参。

一台 Hytale 服务器真正涉及的那些端口

一台 Hytale 服务器只需要一个开放端口：5520 UDP。游戏流量走 QUIC，也就是走 UDP，而游戏流量不需要 TCP。只放行 TCP 的人看到的结果和防火墙关着一样：玩家会走进超时。默认绑定是 0.0.0.0:5520，换别的端口要在启动时用 --bind 设置。

这张表比大多数其他游戏的都短，而这正是最重要的区别。一台 Counter-Strike（反恐精英）服务器用 Steam 的 A2S 格式回答状态查询，一台 Minecraft Bedrock（我的世界基岩版）服务器回应 Unconnected Ping，一台 Palworld 服务器另开一个自己的查询端口。而对 Hytale 来说，公开文档里除了 5520 UDP 没有描述任何其他端口：没有查询端口，没有 RCON 端口，出厂状态下也没有 REST 接口。一台 Hytale 服务器对外提供的全部东西，都落在一个 UDP 端口上。

Hytale 服务器的数字

下面这些值是每一个关于过滤规则和阈值的决定的基础。来源都一并写出，因为它决定了这些值能承受多少重量。

QUIC 改变了攻击面的哪些地方

QUIC 是一种在 UDP 上建立安全连接的传输协议，并把按 TLS 1.3 的加密握手固定内建在里面。不存在未加密的 QUIC。对服务器运营者来说，这意味着两件互相矛盾的事，而两件都重要。

第一件是真正的改善。因为 UDP 不强制连接建立过程，而且发送方地址可以伪造，所以无连接的 UDP 服务是攻击第三方的经典放大器。QUIC 在标准里限制了这一点。RFC 9000 第 8.1 节规定，服务器在校验发送方地址之前最多只能发送所收到字节量的三倍，第 14.1 节要求客户端把自己的第一个数据报填充到至少 1200 字节。这两条规则合起来，把一个 QUIC 服务的放大系数压到最高 3，而一个 Steam 查询端口或一个 Bedrock 的 Unconnected Ping 会达到它的好几倍。因此一台正常工作的 Hytale 服务器作为反射放大器几乎没有价值。这是相对于几乎所有其他使用 UDP 流量的游戏的结构性优势，和 Minecraft Bedrock 服务器对比时尤其明显。

第二件是为此付出的代价。一次 QUIC 连接建立要消耗服务器的计算时间，因为它包含一次带非对称加密运算的 TLS 1.3 握手协商。单个伪造的数据包无法迫使服务器完成一次建立，但来自僵尸网络的大量真实连接尝试可以。攻击者同样要付出计算时间，而恰恰是这个比例决定一切：只要服务器为每次连接尝试做的工作比攻击者多，这次攻击就是经济的。因此一场连接尝试的洪水攻击压的不是线路，而是处理器，并且在带宽统计里看起来什么事都没有。这和 Minecraft 上被称为 Nullping 和握手洪水攻击的是同一套机制，文章 Minecraft DDoS 防护与 Nullping 防护对此有详细描述。

这里面在实践中最能用上的，首先是那条 1200 字节规则。一次新的连接尝试必须以至少 1200 字节的数据报到达，否则按标准它就不是一次有效的连接建立。而运行中的游戏流量主要由小数据包组成。这个区别可以浇成一条过滤规则，我们马上就讲到。

关于 Hytale 哪些内容没有公开文档

这份清单属于一篇诚实的文章，因为它划定了您在哪些地方不可以依赖数字。以下全部内容截至 2026 年 9 月 27 日均无官方依据：

• 服务器是否使用 QUIC Retry 来校验地址。RFC 9000 在第 8.1.2 节允许使用带令牌的 Retry 数据包，服务器借此在绑定资源之前校验发送方地址。Hytale 是否这样做、从多大负载起这样做，都没有文档记载。请假定您不能依赖它。
• config.json 中 RateLimit 和 ConnectionTimeouts 两个块的默认值。这两个块存在这一点在多个来源上是一致的。但所提到的数字互相矛盾：一个来源给出具体的阈值，另一个描述这两个块存在但不起作用。因此本文里不写这些数字中的任何一个，也因此您不应该把这两个块当成自己的防守来规划。
• 认证模式的名称和默认值。针对已公开服务端代码的社区文档描述了三种模式，通过 --auth-mode 设置，authenticated 为默认，另有 offline 和 insecure 用于私有环境和开发。这一点没有获得官方确认。但由此推出的规则仍然明确：不要为一台公开服务器改动这个模式。
• TLS 建立过程的细节。基于已公开服务端代码的社区协议文档描述了双向证书、一份在启动时生成的自签名服务器证书（其 SHA-256 指纹经由会话服务送到客户端），以及被关闭的 0-RTT。这说得通，也和 TLS 1.3 相符，但没有获得官方确认，而且它不改变下面那些措施。
• 专门针对 Hytale 服务器的攻击规模。这方面没有公开数字。表里提到的 5 到 50 Gbit/s 是跨游戏服务器项目的经验数据，明确不是 Hytale 的统计。
• 正常运行状态下每名玩家的数据包速率。这方面同样没有可靠的公开资料。因此本文里没有可以让您不加检验就照搬的阈值，只有一份自己去测的说明。

在花钱之前，您自己能做的事

下面这些步骤挡不住流量型攻击，那是服务器上的任何软件都做不到的。但它们能清掉这条线以下的一切：端口扫描、来自少数来源的连接尝试洪水、通过额外安装的管理界面进行的接管尝试，以及被外人把所有位置占满。这就是日常里干扰一台 Hytale 服务器的绝大部分内容，而它要花的时间是一个多小时。

1. 清点：服务器上有什么在监听？

在写下第一条规则之前，先看清楚您的服务器对外提供了什么。不要猜，要查：

ss -lntup

要看的是本地地址那一列。0.0.0.0:5520 表示“整个互联网都能访问”，127.0.0.1:8080 表示“仅本机”，不需要放行。在一台长期使用的机器上，除了服务器的 Java 进程之外，这里经常还会出现一个管理面板、一个用于地图展示的 Web 服务器和一个数据库。从外面做一次端口扫描，就能看到攻击者眼中的样子：

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

第二条命令更重要。它显示还有什么在对外开着，而在实践中这几乎总是比预想的多。

2. 只留 5520 UDP，其余全部关掉

两条放行就够了。用 UFW 的写法如下，而且顺序必须完全照此执行，以免把自己关在门外：

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

5520 上的 TCP 放行您不需要。如果您把服务器跑在另一个端口上，放行必须和 --bind 里的值一致，否则启动会正常完成，而玩家照样进不来。包含自救办法的完整说明见 设置 UFW 防火墙而不把自己关在门外。

对于所有您为了管理额外安装的东西，规则和其他任何游戏一样：不要放进开放的网络，而是通过 SSH 端口转发访问，然后在本地对着 127.0.0.1 操作：

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

3. 按它本来的设计启动服务器

启动只有一条命令。服务器文件通过官方 Hytale 下载器获取，或者来自您自己的游戏安装：

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

第一次启动时，服务器会创建 config.json、目录 logs/ 和世界目录 universe/。之后请把它在自己的账号上登录一次，让玩家认证能正常工作。这一步通过服务器控制台里的设备码完成：

/auth login device
/auth status

不要把 -Xmx 设成机器的全部内存。操作系统、文件系统缓存和堆之外的 Java 运行开销同样需要空间，而一台在负载下用到交换空间的服务器，在您玩家看来和一次攻击完全一样。

4. 用白名单、服务器密码和玩家上限对付槽位耗尽

槽位耗尽是对一台社区服务器最便宜的攻击，而且不需要带宽。谁建立足够多的并发连接，就能占满所有位置，从而把真正的社区关在门外，一个吉比特都不用买。和某些别的游戏不同，Hytale 在出厂状态下就带着合适的工具：whitelist.json 里的白名单、bans.json 里的封禁列表、permissions.json 里的权限，以及 config.json 里的键 Password 和 MaxPlayers。

{
  "ServerName": "我的 Hytale 服务器",
  "MOTD": "",
  "Password": "只有您的团队才知道的值",
  "MaxPlayers": 40,
  "MaxViewRadius": 12
}

Password 出厂是空的，所以任何知道地址和端口的人都进得来。对一台封闭服务器来说，设一个密码是对付槽位耗尽最有效的单项措施；对一台公开服务器来说，在一波攻击期间起作用的是白名单。而有一点必须清楚：服务器密码保护的是您的位置，不是您的线路。灌包攻击您服务器的人根本不想加入。

请只在服务器停止时编辑这些文件。运行中的服务器进程在内存里保有自己的一份状态，可能在关闭时把您在此期间写进文件的改动无声地覆盖掉。运行中要改动，请用控制台命令而不是编辑器。

5. 把认证保持在默认值上

默认模式要求每名玩家都有一个有效的 Hytale 账号。这不只是一次许可检查：它是一道把批量账号变贵的准入过滤。一个想占位置的攻击者为此需要有效账号，而账号要花钱。请不要把这道过滤拿掉。

社区文档在默认模式之外还描述了两种用于私有环境和开发的模式，用它们可以不经账号检查就加入。对一台公开服务器来说，它们是能做到的最差设置，因为它们把槽位耗尽从一个花钱的问题变成一个写脚本的问题。如果您为了测试要切过去，请在一台不连互联网的机器上做，做完再切回来。

6. 限制新的连接尝试，而且要用那条 1200 字节规则

现在 QUIC 的结构性优势要派上用场了。按 RFC 9000，一次有效的连接建立以至少 1200 字节的数据报到达。运行中的游戏流量明显更小。因此借助连接跟踪（conntrack），您可以把新的数据流和已有的区分开，并丢弃所有既是新的又太小的东西。用 nftables，通过 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
    }
}

第一条规则作用在 UDP 长度上，也就是 8 字节包头加 1200 字节负载，合起来 1208。它只会命中那些想开启一条新数据流、却为此太小的数据包，而且不可能命中已连接的玩家。第二条规则限制单个源地址每秒可以开启多少条新连接。每秒五条是宽松的：一个真实玩家建立一条连接就一直保留着。优先级 -10 保证这两条规则在 UFW 的过滤链之前生效。

在游戏端口本身上按源地址给数据包速率设一个上限，是第三条有意义的规则，而这里要明确说：这个数值是起始值，不是真理。

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

请先在正常运行状态下测一周，然后把上限设成所测峰值的两倍。Hytale 对此没有公开的参考数字，而这些值很大程度上取决于玩家数和视距。设得太紧的人会把自己的玩家赶出去，而且先被赶出去的正是线路最差的那些。

纯 iptables 规则在重启后就没了。在 Debian 和 Ubuntu 下这样保存：

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

在 UFW 下，这类规则还应写进 /etc/ufw/before.rules，否则下一次 ufw reload 时就会消失。一条规则到底有没有被走到，用 iptables -L INPUT -n -v 就能看出来：命中计数器停在零，它就没起作用。

7. 把内核的连接跟踪调对

这一点解释了那些看起来像流量型攻击、其实不是的宕机。内核会为 UDP 流量在连接跟踪里建条目，而在发送方地址被伪造的情况下，每个地址都意味着一个新条目。表一满，内核就不加区别地丢弃数据包，攻击和您的玩家一起被踢出去，日志里会出现“nf_conntrack: table full”。当前数量和上限用这条命令查看：

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

在大多数游戏上，对此最好的回答是干脆不跟踪游戏流量。在 Hytale 上这是一次真正的权衡，因为第 6 步里那条 1200 字节规则需要连接跟踪。没有它，过滤器就不知道哪个数据包是在开启一条新数据流。因此建议是：保留跟踪，把表加大，把 UDP 的超时保持得短。放在 /etc/sysctl.d/ 下的一份追加配置，用 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

如果还是想关掉跟踪，例如在一台同时在线玩家非常多的机器上，那就在 raw 表里设 udp dport 5520 notrack，同时放弃那条 1200 字节规则。两者不能同时要。对一台单独的 Hytale 服务器来说，这条规则比省下来的表条目更值钱。

如果数据包到达得比 Java 进程取走的更快，接收缓冲区还会溢出。在玩家看来这像丢包，尽管线路是空的。上面那些缓冲区设置到底有没有必要，内核自己会告诉您：如果 nstat -az 里的 UdpRcvbufErrors 在上升，它们就起作用。计数器停在零，这些调整就什么都不改变。

8. 把视距和玩家数选得和线路相称

这一步不是安全措施，但它决定了您到底能承受多少攻击。Hypixel Studios 在 2025 年 12 月 1 日的官方硬件要求里说得很清楚：视距翻一倍，玩家周围的世界量就变成四倍。官方建议最多 12 个区块，也就是 384 个方块，通过 MaxViewRadius 设置。在客户端一侧，同一份要求给出每名玩家多人游戏的最低 2 Mbit/s 和建议 8 Mbit/s。

请为您的服务器把这个算一遍。一台 40 名玩家、视距给得比较宽的服务器，在正常运行状态下会跑出低三位数的兆比特量级。这就是您的线路必须去比的数值，同时也是一次攻击必须超过才会被注意到的数值。把一条 1 Gbit/s 的线路在正常运行状态下填掉三分之一的人，余量比只用到百分之五的人少。因此更小的视距不只是性能问题，也是稳健性问题。

9. 盯住 Mod、插件和协议变更

Hytale 在服务端可以装 Mod：Mod 以 .zip 或 .jar 放在 mods/ 目录里，插件则直接对接服务器接口。这很方便，因为玩家不用装任何东西，同时它也是一个与攻击无关的可用性风险。一个每收到一次网络事件就做昂贵工作的插件，就是您自己家里的放大器。

再加上协议变更。按 2026 年 8 月 27 日的官方更新说明，随着 Update 6，网络协议从 hytale/2 变成了 hytale/3，服务器和插件必须重新构建才能连上。对可用性来说这意味着：给您的 Mod 列一份清单并记上版本，每次更新之前在第二个实例上验一遍，并在 2026 年 10 月 12 日之前安排一个维护窗口。一台更新之后起不来的服务器，在您玩家看来和一次攻击没有区别。

10. 在出事之前先攒测量数据

最重要的一步是几乎没人事先做的那一步：在一切正常的时候先建立基线。没有正常值，事发之后您就说不清每秒 4 万个数据包是很多，还是就是个普通的周六晚上。用 apt-get install -y vnstat sysstat conntrack 让测量常驻运行。事件发生时五条命令就够了：

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"

用 tcpdump 时有一条铁律：一定要用 -c 限制数量，满载状态下抓包会让本来已经过载的服务器更吃力。因为 Hytale 服务器跑在 Java 上，您还需要第二项检查来排除最常见的误报。垃圾回收的一次停顿，在玩家看来和一次攻击完全一样：所有人同时卡住，之后又继续。区别就在数字里。

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

解读很简单。入向数据包远高于正常值，而 Java 进程几乎不干活，那就是一次攻击。数据包速率毫无异常，而堆内存被填满或者日志显示出长时间停顿，那就是负载。网络数值具体怎么解读，见 在服务器上识别 DDoS 攻击。

11. 备份、回退方案，以及大日子之前的一次试运行

一套从未测试过的防护方案只是一个猜测。在 2026 年 10 月 12 日这样的日子之前，有四件事该做完：一份放在机器之外的 universe/ 目录连同 config.json 的备份、一条验证过的回到上一个服务器版本的路、一个先在上面装更新的第二实例，以及一次会触发您自己过滤规则的压力测试。

压力测试是大多数运营者停下来的地方，而它最重要。您要检验的不是您的规则能不能挡住攻击，而是它们能不能放过您自己的玩家。为此只要在二十名真实玩家同时加入时盯着命中计数器就够了。如果这时丢弃规则的计数器在上升，说明您的上限设得太紧，而否则您会在更新当天、在最差的条件下才发现这件事。

这些措施到哪里为止：带宽和数据包速率

现在说没有任何配置文件能解决的那一部分。前面所有措施都跑在您的服务器上，也就是线路的末端。防火墙规则处理的是已经跑过网线的数据包。您可以把它丢弃，但没法让它没被发出来。

一起算一下。一台典型的游戏服务器挂在 1 Gbit/s 上，也就是每秒 125 兆字节，只要有人发得更多，线路就满了。针对游戏服务器项目的攻击通常在 5 到 50 Gbit/s 之间，也就是您线路的五倍到五十倍。到那时，您后面的 nftables 规则写得好不好都无所谓了，因为您玩家的数据包在更早的地方就已经过不来了。

第二个量是数据包速率，而它常常比带宽先出事。在 64 字节的小包情况下，1 Gbit/s 的线路里能装进每秒约 149 万个数据包。普通的服务器内核视处理器和网卡而定，处理其中几十万个之后就会开始丢弃。所以一次连您线路三分之一都填不满的攻击，也可能让您的服务器瘫掉，因为计算时间都花在丢弃上了。运营者的体验是“负载根本不高，可是什么都没了”。

在 Hytale 上还多出第三个量，大多数游戏没有这一项：连接建立的计算时间。来自僵尸网络的一场有效连接尝试洪水，既填不满线路，也不产生显眼的数据包速率，它用加密运算把处理器占住。这类攻击在带宽统计里是看不见的，在 Java 进程的处理器负载里却很明显，而只要来源足够多，按源地址的速率限制和更大的接收缓冲区都帮不上忙。

为了说明现实中会出现哪些量级：在 KernelHost 的服务器上，过滤掉的攻击里包括一次针对语音服务器、超过 473.4 Gbit/s 且每秒超过 4150 万个数据包的攻击，以及一次针对游戏服务器、超过 112.2 Gbit/s 的 UDP 洪水攻击。对此没有任何本地设置可用。流量型攻击必须在服务器前面的网络里就被终结。

KernelHost 用什么应对针对 Hytale 服务器的 DDoS 攻击

每个服务器套餐里都包含的持续防护

KernelHost 的 DDoS 防护分两级，持续生效，您不需要开启、订购或配置任何东西：

• 第 1 级：全球清洗网络中 17 Tbps 的清洗能力。流量型攻击在靠近来源的地方就被清洗掉，不会到达数据中心。
• 第 2 级：法兰克福的 Arbor 实时过滤，容量 3.2 Tbps。就在服务器前面，逐个数据包地识别并丢弃与协议相关的攻击特征。

有两点是关键。防护持续运行，不需要先对攻击做出反应，所以开头不会有服务器失联的那几分钟。而且不使用黑洞路由：您的 IP 地址留在网络里，被丢弃的只有恶意数据包。把 IP 地址从网络里撤下来的做法，对您而言和攻击者达到的结果一样。哪些作品和协议有自己的防护策略，见 实时游戏服务器 DDoS 防护。

针对长期被攻击的 Hytale 项目的 Advanced DDoS Protection

有些项目不是偶尔被打，而是被有针对性地连打几周，而在一款处于 Early Access 的游戏里，这尤其会落在那些正在成长的服务器上。为此有 Advanced DDoS Protection，每月 50.00 欧元起，PrePaid 预付费，没有最低合约期，也没有开通费。区别不在于容量更大，而在于控制权：

• 专用防护 IP，来自法兰克福的核心网络，您的服务器会在我们自己的网络内切换到它。您这边不需要做任何改造。
• 按端口和协议自行管理的防护规则，就在客户中心里：您自己定 5520 UDP 上允许什么，与其他一切分开设置，而且不需要开工单。
• 改动实时生效，因此您可以在攻击进行时随时调整，例如短时间内把新连接管得更紧，同时让运行中的游戏流量不受影响。
• 与协议匹配的规则集，既适用于 UDP 上的 QUIC，也适用于任意 TCP 或 UDP 端口上的自研程序。

Advanced DDoS Protection 面向放在 KernelHost 的服务器。谁目前把自己的 Hytale 项目跑在别处并且长期被攻击，就为此把它迁到 KernelHost 来，那么两级防护自开通起就都生效。

两级防护对比

对大多数 Hytale 服务器来说，标配的持续防护配上干净的服务器配置就够了。Advanced DDoS Protection 针对的是有人把这件事当成私人恩怨的情况。

哪些经验可以从别的游戏搬到 Hytale 上

因为 Hytale 还年轻，而且针对 Hytale 服务器的攻击没有公开数字，所以拿到可靠知识最快的路子是去看可比的游戏。能搬过来的不是端口号，而是模式。

• 爆发式的开局以及它引来的东西：Palworld 展示了一波新玩家和一波攻击如何在时间上重叠，以及为什么恰恰是正在成长的服务器会成为目标。
• 查询和游戏流量的区别：Minecraft Bedrock 用 Unconnected Ping 解释了经由 UDP 的放大是怎么工作的。Hytale 借着 QUIC 正好没有这条攻击路径，而这个区别在那里最容易理解。
• 把连接建立当成攻击目标：Minecraft DDoS 防护与 Nullping 防护 描述了几乎不需要带宽的握手洪水攻击。这是 QUIC 连接洪水攻击最近的亲戚。
• 玩家数少与槽位耗尽：Project Zomboid（僵尸毁灭工程）和 Conan Exiles（流放者柯南）展示了把一个固定的小团体关在门外只需要多少功夫，以及白名单和密码在其中起什么作用。
• 持续负载下的运行：Terraria（泰拉瑞亚）展示了一个带单核负载的单独服务器进程如何对攻击做出反应。Hytale 服务器是一个 Java 进程，基本问题是可比的。

Hytale 服务器上常见的错误及解决办法

“我放行了 5520 TCP 端口，玩家还是进不来”：游戏流量走 QUIC，也就是走 UDP。TCP 放行对游戏流量没有任何作用。请放行 5520 UDP，并用 nmap -Pn -sU -p 5520 从外面检查。如果您用 --bind 把服务器放到了另一个端口上，放行就必须写那个端口。

“服务器在跑，但谁也加入不了，日志里也没有攻击的迹象”：请用 /auth status 检查服务器在自己账号上的登录状态。一台登录已过期的服务器会继续运行，却照样拒绝玩家。这不是网络问题，也不是过滤规则的问题。

“更新之后什么都起不来了”：这不是攻击，而是协议变更。随着 Update 6，网络协议从 hytale/2 变成了 hytale/3，服务器和插件都需要重新构建。请先在第二个实例上装更新，再放到生产服务器上。

“所有玩家同时卡住两秒，然后又继续”：这极有可能是 Java 运行环境的垃圾回收，而不是攻击。请检查 jcmd ... GC.heap_info 和服务器日志。如果这时 sar -n DEV 1 10 毫无异常，那就没有攻击参与，而是堆给得太紧或者视距太大。

“我那条针对小数据包的规则把玩家关在外面了”：那说明链里的 1200 字节条件没有带 ct state new。运行中的游戏流量主要由小数据包组成，而一个不做状态判断的长度条件正好命中它们。这个条件只适用于新开启的数据流。

“我换了 IP 地址，两小时之后又离线了”：攻击者拿到新地址的渠道和拿到旧地址的一样。在 Hytale 上这通常是 DNS 里一条旧的 A 记录、一个带状态显示的 Discord 机器人，或者第三方那许多服务器列表中的一条记录。自 Update 6 起，官方服务器列表里的服务器地址默认是隐藏的，这关掉了最方便的那条路，但不是所有路。换地址是争取时间，不是解决办法。

“我的过滤规则不起作用”：常见原因有三个。规则排在 UFW 的链后面，永远轮不到它；规则在上次重启后就没了（这时用 netfilter-persistent save，或者写进 /etc/ufw/before.rules）；或者攻击是流量型的，而规则在一条已经满了的线路上正常工作。用 iptables -L INPUT -n -v 检查命中计数器是否在增长。

“我原来的主机商把我的 IP 地址封了”：那就是黑洞路由。主机商用它保护自己的网络，对您来说结果和一次成功的攻击完全一样，而且通常在攻击结束后还要持续几个小时。有疑问时请直接问清楚：是过滤还是黑洞路由。这个答案对您可用性的影响，比任何硬件参数都大。

“我在 tcpdump 里看不到任何异常”：如果流量已经在前面的网络里被过滤掉了，服务器上当然就什么都收不到。这在过滤正常工作时是常态。反过来说：线路一旦被打满，您甚至可能连用来测量的那条 SSH 会话都进不来。这时请使用客户中心里的 VNC 控制台，它独立于客户机自身的网络运行。

要点总结

• 一台 Hytale 服务器只需要一个开放端口：给 QUIC 用的 5520 UDP。游戏流量不需要 TCP，而公开文档里没有描述任何用于查询、RCON 或远程控制的其他端口。
• 因为按 RFC 9000，QUIC 在地址校验之前最多只能发送所收到字节量的三倍，而第一次连接尝试必须至少 1200 字节大，所以一台 Hytale 服务器作为反射放大器几乎没有价值。这一点把它和带 Steam 查询或 Bedrock Unconnected Ping 的服务器区分开来。
• 同样这条 1200 字节规则是最好的本地过滤规则：想在 5520 UDP 上开启一条新数据流而又更小的东西，不可能是一次有效的连接建立，可以丢掉，而且不会碰到已连接的玩家。
• 一次 QUIC 建立里贵的部分是加密运算，不是带宽。一场有效连接尝试的洪水在带宽统计里看不见，只能在处理器负载和每秒新连接数的计数里看到。
• 带账号要求的默认模式是一道把批量账号变贵的准入过滤。对一台公开服务器来说它不该被动，再加上 whitelist.json、bans.json 和一个设好的 Password 来对付槽位耗尽。
• 本地措施到线路为止：1 Gbit/s 是每秒 125 兆字节，在 64 字节的包大小下那里能装进每秒约 149 万个数据包。超过这个的一切都必须在服务器前面的网络里终结。
• Hytale 自 2026 年 1 月 13 日起处于 Early Access，Chapter 1 已宣布定在 2026 年 10 月 12 日。大日子就是攻击的日子，而在当天才下单的防护来得太晚。
• 在 KernelHost，两级持续防护包含在每个服务器套餐中，不额外收费，自开通起即生效，并且不使用黑洞路由。带专用防护 IP 和可按端口自行管理规则的 Advanced DDoS Protection 从每月 50.00 欧元起。

如果您的 Hytale 服务器已经放在 KernelHost，过滤就已经在工作，您什么都不用做。若仍然发现异常，请开一个 支持工单，以便为您的 IP 地址调整过滤规则。攻击正在进行时，您还可以通过 WhatsApp 紧急聊天联系我们：+43 650 8209883。

本文的状态截至 2026 年 9 月 27 日。Hytale 处于 Early Access，网络协议在今年已经变过一次。每逢 Chapter 1 以及任何涉及连接建立、端口或服务器列表的更新之后，本文都会继续更新。