保护 Palworld 服务器免受 DDoS 攻击

一台 Palworld 服务器如果在晚上游戏进行到一半时把所有玩家同时踢下线，离线几分钟，之后又自己恢复可访问，那问题很少出在硬件上。多数情况下是有攻击正在进行。本文讲的是怎样为 Palworld 服务器做好 DDoS 防护：先讲您不花额外费用就能自己配置的部分，然后讲这些措施在技术上到哪里为止，最后讲服务器前面的网络里必须发生什么，服务器才能保持可访问。

本文所有内容针对 Pocketpair 官方的独立服务器（Steam 应用编号 2394010），运行在 Debian 12、Debian 13、Ubuntu 22.04 LTS 或 Ubuntu 24.04 LTS 上。命令以 root 身份书写，普通用户请在前面加上 sudo。如果攻击正在进行，有一个次序要守：先测量，再改动。带着负载硬重启，会把世界里自上一个自动存档点以来发生的一切都丢掉，而且事件的测量数据随后也就没了。

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

一台 Palworld 服务器就是一个固定地址上的小而固定的玩家群体。独立服务器最多 32 名玩家，通过 ServerPlayerMaxNum 控制，有效范围是 1 到 32。改用游戏菜单里的主机模式，则只有四名玩家，而且只在主机本人在线期间有效。后面的一切都从这 32 个位置推出来：这群人在固定的晚间时段游戏，彼此都认识，晚上 8 点的一次宕机影响的不是一部分玩家，而是全部。

服务器的地址在这里不是秘密。Palworld 没有任何经由厂商服务的中转：玩家把 IP 地址和端口填进直连输入框，想让服务器同时出现在社区服务器列表里的人，则用 -publiclobby 启动它，并让查询端口回答请求。于是任何连过一次的人都知道目标在哪。一个每月几欧元就朝这个地址开火的 booter 服务，对下单的人既不要求本事，也不要求花功夫。

技术上还要加一点：全部游戏流量都走 UDP。UDP 没有可以强制要求的连接建立过程，而 UDP 数据包的源地址可以伪造。因此攻击者既不必进入服务器，也不必正确地跟它对话，就能制造负载。这样一次攻击在技术上发生了什么，请看文章 什么是 DDoS 攻击？。

在 Palworld 服务器上真正相关的那些端口

一台 Palworld 服务器正好需要一个对外开放的端口：8211 UDP。其余都是可选的，而且视用途而定，放在互联网上甚至是有害的。由此得出一个有用的区分：针对 8211 端口的 DDoS 攻击打的总是游戏流量本身，而针对 27015 UDP 端口的攻击只打服务器列表里的那个条目。

相关的开关全都在一个文件里：Pal/Saved/Config/LinuxServer/PalWorldSettings.ini，在 Windows 上对应 Pal\Saved\Config\WindowsServer\PalWorldSettings.ini。文件以节标题行 [/Script/Pal.PalGameWorldSettings] 开头，随后是唯一一行 OptionSettings=(...)，所有设置都以列表形式写在里面。括号内出现一个换行就会让整份配置失效，服务器会不声不响地退回默认值。服务器目录里的模板 DefaultPalWorldSettings.ini 不要去改，因为它在每次更新时都会被覆盖。

Palworld 服务器的关键数字

下面这些数值是关于过滤规则和阈值的每一个决定的基础。

为什么查询端口 27015 是最脆弱的一点

查询端口回答的是 Steam 的 A2S 格式状态请求，也就是 Counter-Strike 和 ARK 服务器同样在处理的那种查询。一次 A2S_INFO 请求是一个几十字节的无连接 UDP 数据包，而带有服务器名称、世界、玩家数和游戏进度的回应是它的好几倍。由于 UDP 的源地址可以伪造，攻击者可以去问别人的查询端口，把较大的回应引到自己真正的目标上。在这种情况下，您的服务器不是受害者，而是放大器，代价由它的线路来付。

为此，Valve 在 2020 年 12 月 8 日给 A2S_INFO 加了一道前置的挑战值机制：服务器先用 S2C_CHALLENGE 回应，请求方必须把令牌送回来，从而证明自己没有伪造源地址。这缓解了放大效应，但没有终结它，而且对来自真实地址的同类查询洪水攻击完全不起作用。

对 Palworld 来说，由此得出一个相对 Source 引擎的重要优势：游戏流量和服务器查询位于彼此分开的端口上。在 Counter-Strike 2 上两者共用 27015 端口，粗糙的速率限制会把自己的玩家一起踢出去。在 Palworld 上，您可以把 27015 UDP 限得很死甚至完全关掉，而丝毫不碰 8211 UDP 上正在进行的游戏流量。不需要列表条目的人，直接去掉 -publiclobby 和查询端口，不做任何替代，这样就把一整块攻击面从网络里拿走了。

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

下面这些步骤挡不住流量型攻击，服务器上的任何软件都做不到这一点。但它们能清掉这条线以下的一切：端口扫描、查询洪水攻击、通过管理端口的接管尝试，以及被外人占满全部 32 个位置。日常里干扰一台 Palworld 服务器的，大部分就是这些，而做完只要半小时。

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

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

ss -lntup

要看的是本地地址那一列。0.0.0.0:8211 表示“整个互联网都能访问”，127.0.0.1:8212 表示“仅本机”，不需要防火墙规则。在一台用了一段时间的服务器上，除了游戏进程之外，这里往往还会出现一个管理面板、一个用于地图显示的 Web 服务器和一个数据库。从外面做一次端口扫描，就能看到攻击者眼中的样子：

nmap -Pn -sU -p 8211,27015 YOUR.SERVER.IP.ADDRESS
nmap -Pn -p- --min-rate 1000 YOUR.SERVER.IP.ADDRESS

2. 只开放 Palworld 真正需要的东西

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

ufw allow 22/tcp comment 'SSH'
ufw allow 8211/udp comment 'Palworld 游戏流量'
ufw allow 27015/udp comment 'Palworld Steam 查询'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

如果您不希望服务器出现在社区服务器列表里，就把第三行去掉。您的玩家依然通过 IP 地址和 8211 端口连接，服务器只是从公开列表里消失。包含自救办法的完整说明见 设置 UFW 防火墙而不把自己关在门外。

3. 把 25575 上的 RCON 和 8212 上的 REST API 从互联网上撤下来

这两个端口都是拥有服务器完全控制权的管理入口，而且出厂时都是关闭的：RCONEnabled=False 和 RESTAPIEnabled=False。打开它们的人，应该清楚自己因此公开了什么。

8212 TCP 上的 REST API 通过 HTTP Basic Auth 认证，用户名固定为 admin，密码取自 AdminPassword，而且走的是未加密的 HTTP。于是管理密码在每一次请求里都以可还原的形式跑过线路。25575 TCP 上的 RCON 同样是未加密的文本协议，Pocketpair 已经把它标记为过时，转而推荐 REST API。对新安装来说，REST API 是正确的选择，而两者适用同一条规则：不要放到公网上。

RESTAPIEnabled=True
RESTAPIPort=8212
AdminPassword="a long random value"

要访问这个接口，请用一条 SSH 端口转发，之后就在本机对着 127.0.0.1:8212 操作：

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

AdminPassword 绝对不要留空，因为默认值就是空的。用 openssl rand -base64 32 生成一个值就够了。ServerPassword 同理，下面马上会讲到。

4. 给查询端口 27015 限速，又不丢掉列表条目

无连接的 Steam 数据包以四个全置位的字节（0xffffffff）开头，正常的游戏流量没有这个头。可以据此按源地址加一条速率限制，既刹住查询，又保住列表条目。用 nftables，通过 nft -f 加载：

table inet palworld {
    chain input {
        type filter hook input priority -10; policy accept;
        udp dport 27015 @th,64,32 0xffffffff \
            meter a2sflood { ip saddr limit rate over 10/second burst 20 packets } drop
    }
}

优先级 -10 让这条规则在 UFW 的过滤链之前生效，而 @th,64,32 读取的是 UDP 头后面的前四个字节。用传统的 iptables，同样的区分靠匹配 A2S_INFO 的标识来实现：

iptables -A INPUT -p udp --dport 27015 \
  -m string --algo bm --hex-string "|ffffffff54536f7572636520456e67696e6520517565727900|" \
  -m hashlimit --hashlimit-name a2sflood --hashlimit-mode srcip \
  --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP

每个地址每秒十次查询定得很宽松：列表服务通常每隔几分钟才问一次，不是每秒好几次。要紧的只有一点：这条规则必须作用在 27015 上，而不是 8211 上，否则打到的是您自己的玩家。

5. 给 8211 UDP 上的数据包速率设上限

在游戏端口本身，一个按源地址的上限能对付来自少量来源的小型洪水攻击。在 Palworld 上设这个上限相对来说风险不大，因为同时连上的玩家最多 32 名，而每个人正好占用一个源地址：

iptables -I INPUT -p udp --dport 8211 \
  -m hashlimit --hashlimit-name palworld_udp --hashlimit-mode srcip \
  --hashlimit-above 400/sec --hashlimit-burst 600 -j DROP

这个数字是起始值，不是真理。一台有 32 名玩家和许多基地的满员服务器产生的数据包，比四个人的一局多得多，设得太紧会把自己的玩家踢出去。请先在正常运行状态下测一周，然后把上限设为测得峰值的两倍。

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

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

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

6. 服务器密码、封禁列表，以及用 32 个位置对付槽位耗尽

槽位耗尽是针对 Palworld 服务器最便宜的攻击，而且完全不需要带宽。独立服务器最多 32 个位置，所以 32 条同时连接就足以把整个社群挡在门外。流量型攻击要花下单者的钱，32 个会话则一分钱都不要。这就让这条路在小型服务器上比任何洪水攻击都更有吸引力。

Palworld 没有内置白名单。可用的管理手段是踢出、封禁和一个服务器密码，而对付槽位耗尽，服务器密码正是最有效的单项措施：

ServerPassword="a value only your group knows"
ServerPlayerMaxNum=32
bShowPlayerList=True
BanListURL="https://api.palworldgame.com/api/banlist.txt"

ServerPassword 出厂时是空的，所以任何知道 IP 地址和端口的人都能进来。BanListURL 默认指向由 Pocketpair 维护的列表，如果您想自己管项目内的封禁，也可以把它改到一份自有的文本文件上。ServerPlayerMaxNum 不要设到 32 以上：更高的值不受支持，最晚到下一次更新时就会出问题。还有一点必须清楚：服务器密码保护的是您的位置，不是您的线路。向您服务器灌包的攻击者根本不想进服。

7. 给连接跟踪减压，并把缓冲区调大

这一点解释了那些看着像流量攻击、实际上不是的故障。内核会为 UDP 流量在连接跟踪（conntrack）里建立条目，而在源地址被伪造的情况下，每一个地址都意味着一条新条目。表一满，内核就不分青红皂白地丢弃数据包，攻击和您的玩家一起被丢出去，日志里会出现“nf_conntrack: table full”。当前数量和上限用这条命令查看：

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

最有效的一步是干脆不让游戏流量进入跟踪，因为 Palworld 自己管理它的会话：

table inet raw {
    chain prerouting {
        type filter hook prerouting priority raw; policy accept;
        udp dport { 8211, 27015 } notrack
    }
    chain output {
        type filter hook output priority raw; policy accept;
        udp sport { 8211, 27015 } notrack
    }
}

用 iptables，对应的写法是 iptables -t raw -A PREROUTING -p udp --dport 8211 -j NOTRACK，以及同一行针对 OUTPUT 并改用 --sport 的版本。此后这些端口需要一条明确的放行规则，因为没有跟踪，任何检查已有状态的规则都不再生效。如果数据包到达的速度比服务器进程取走的速度更快，接收缓冲区还会溢出。对玩家来说这看着像丢包，尽管线路是空闲的。可以在 /etc/sysctl.d/ 下加一份配置，用 sysctl -p 生效：

net.core.rmem_max = 16777216
net.core.rmem_default = 1048576
net.core.netdev_max_backlog = 16384

这些数值是否有必要，内核自己会告诉您：如果 nstat -az 里的 UdpRcvbufErrors 在上升，那它们就有用。计数器一直是零，这项调整就什么也改变不了。

8. 在出事之前先收集测量数据

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

sar -n DEV 1 10
ip -s link show eth0
dmesg -T | tail -50
tcpdump -ni eth0 -c 200 "udp port 8211 or udp port 27015"

用 tcpdump 时有一条铁律：一定要用 -c 限制数量，满载状态下抓包会让本来已经过载的服务器更吃力。Palworld 还额外提供了一个别的工具都没有的测量指标。如果启用了 REST API，指标接口会返回服务器帧率、当前玩家数和运行时长等信息：

curl -s -u admin:YOUR_ADMIN_PASSWORD http://127.0.0.1:8212/v1/api/metrics

就这一个数字，能把两种最常见的原因干净地分开。如果服务器帧率掉下来，而数据包速率并无异常，那不是攻击，而是负载，或者是服务器进程那个众所周知的内存持续增长。如果帧率保持稳定，而入向数据包远远高出正常值，那就是攻击。如何逐项解读网络数值，见 在服务器上识别 DDoS 攻击。

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

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

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

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

在 Palworld 服务器上还多出一个不利的比例关系。一台坐满 32 名玩家的服务器只用掉 1 Gbit/s 线路的一小部分。因此攻击不需要很大，就能达到正常运行量的好几倍，正因如此，在这里连那些放到大平台上根本不会被注意的攻击都已经够用了。

为了让您对现实中的量级有个概念：在 KernelHost 的服务器上，曾经过滤过一次打向语音服务器、超过 473.4 Gbit/s、每秒超过 4150 万个数据包的攻击，以及一次打向游戏服务器、超过 112.2 Gbit/s 的 UDP 洪水攻击。这种情况没有任何本地设置可用。流量型攻击必须在服务器前面的网络里就被终结。

KernelHost 用什么来应对

包含在每个服务器套餐中的持续防护

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

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

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

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

有些项目不是偶尔被打，而是被有针对性地连打几周。为此有 Advanced DDoS Protection，每月 50.00 欧元起，PrePaid 预付费，没有最低合约期，也没有开通费。区别不在于容量更大，而在于控制权：

• 专用防护 IP，来自法兰克福的核心网络，您的服务器会在我们自己的网络内切换到它。您这边不需要做任何改造。
• 按端口和协议自行管理的防护规则，就在客户中心里：您可以分别设置 8211 UDP 上允许什么、27015 UDP 上允许什么，而且不用为此开工单。
• 改动实时生效，因此您可以在攻击进行时随时调整，例如临时把查询端口限得更死，而游戏端口保持不动。
• 与具体游戏匹配的防护策略，对 Palworld 如此，对任意 TCP 或 UDP 端口上的自研程序同样如此。

Advanced DDoS Protection 面向放在 KernelHost 的服务器。目前把 Palworld 项目跑在别处、又长期被攻击的人，为此把它迁到 KernelHost，两级防护自服务器开通起即生效。

两级防护对比

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

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

“我把 27015 封了，现在服务器从社区列表里消失了”：这是预期中的行为，因为列表条目是由查询端口承载的。不要一刀切地封掉它，而要像第 4 步那样按源地址限制无连接数据包。如果您本来就不需要列表条目，那就让端口保持关闭，去掉 -publiclobby，并把 IP 地址和 8211 端口给您的玩家用于直连。

“我换了 IP 地址，两个小时以后又离线了”：攻击者拿到新地址的渠道和旧地址是同一个。在 Palworld 上，这几乎总是三条路之一：一个本来就把地址存在直连输入框里的玩家、一个带状态显示的 Discord 机器人重新公开了它，或者 DNS 里一条指向旧地址的老 A 记录。换地址只是争取时间，不是解决办法。

“服务器有延迟尖峰，可线路很安静”：在 Palworld 上，这更多是负载而不是攻击。服务器进程随着运行时间不断占用更多内存，所以一次有计划的重启属于正常运行的一部分，不该被理解成权宜之计。请通过指标接口检查服务器帧率，以及进程的内存占用。如果此时 sar -n DEV 1 10 一切正常，那就不是 DDoS 攻击。

“32 个位置全占满了，可游戏里看不到人”：这是槽位耗尽，打的是游戏逻辑，不是线路。请设一个 ServerPassword，通过封禁列表封掉可疑账号，并在 8211 UDP 上按源地址限制数据包。

“REST API 有几天是对外可访问的”：那您的管理密码就已经泄露了，因为未加密 HTTP 上的 HTTP Basic Auth 会在每一次请求里以可还原的形式把它传出去。请修改 AdminPassword，对外关闭 8212 TCP，并且以后只通过一条 SSH 端口转发来访问这个接口。

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

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

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

要点总结

• 一台 Palworld 服务器正好需要一个对外开放的端口：8211 UDP。查询端口 27015 UDP 只在需要社区服务器列表里的条目时才用得上。
• 25575 TCP 上的 RCON 和 8212 TCP 上的 REST API 绝不该放到公网上，因为两者都以未加密方式传输访问凭据。RCON 还被 Pocketpair 标记为已过时。
• 由于 Palworld 的游戏流量和服务器查询位于彼此分开的端口上，27015 UDP 可以限得很死，而不碰 8211 UDP 上正在进行的游戏流量。
• 独立服务器最多 32 个位置，所以槽位耗尽是最便宜的攻击。而设好 ServerPassword 是对付它最有效的单项措施，因为 Palworld 没有内置白名单。
• 本地措施到线路为止：1 Gbit/s 就是每秒 125 兆字节，在 64 字节的包大小下能装进每秒约 149 万个数据包。超出这个量的一切都必须在服务器前面的网络里被终结。
• 在 KernelHost，两级持续防护包含在每个服务器套餐中，不额外收费，自服务器开通起即生效，并且不使用黑洞路由。带专用防护 IP 和可按端口自行管理规则的 Advanced DDoS Protection 从每月 50.00 欧元起。

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