游戏服被打应急预案（好友服 / 小公开服）

圣诞前后帮朋友评估一圈小游戏服防护。结论先写在预案抬头：没有免费又完美的魔法。小服最怕被扫到真 IP 后 UDP 洪水；预案的目标不是「永不被打」，而是「被打时知道先做什么、钱花在刀刃上」。

选项矩阵：按人数与公开程度选

矩阵怎么用：先问「服务的是五个朋友还是五百个陌生人」。好友联机优先 VPN 专服；公开社区服再谈高防预算。把防打写进开服预算，而不是上线后的惊喜。直播和截图里不要出现服务器 IP；群公告贴域名而不是裸地址，并做好切换准备。

日常就能做的减暴露

管理端口和游戏端口分离，SSH 只走密钥与非标准端口或 VPN。世界与存档可迁移备份，被打到换机时不至于连档也没。防火墙只放行必要 UDP/TCP。若必须公网，域名 TTL 调短，备用 IP 或隐藏节点提前验证能连通，而不是灾时才第一次解析。部分游戏支持仅邀请或白名单，能开就开——少一个随机扫到的入口。

中继与 CDN 要对症：TCP 游戏有时可套隧道；很多联机游戏走自定义 UDP，CDN 帮不上忙。Spectrum 一类能力强，个人账单通常劝退。高防按防护带宽付费，适合决定长期公开、有流水或强需求的服。换 IP 只能当权宜，遇到针对会很累，还影响玩家书签与 DNS 缓存。

若游戏支持仅监听特定接口或需要 query 端口与游戏端口分离，防火墙规则按文档拆开写，避免「为了图省事全放 0-65535」。状态同步类游戏在切换 IP 后，旧连接残留可能导致部分客户端卡在半连接，预案里加一句：切换后请完全退出客户端再进。

被打时的顺序（照着做，别慌）

1. 确认是不是真打
   看机房流量图、主机网卡、游戏是否可连。别把「存档损坏」或「进程崩了」误判成攻击；也别把攻击误判成「再重启一次就好」。

2. 切换隐藏节点 / 启用备用 IP
   若预案里已有 WireGuard 专服或备用入口，先把真人玩家迁过去。公开 DNS 可临时指到维护页或停更说明。

3. 通知玩家改连或暂停
   群里说清楚：暂停多久、新连接方式是什么、档有没有丢。信息不对称比短暂停服更容易炸群。

4. 评估是否值得上高防
   一次性洪水 vs 持续针对；好友局 vs 公开招人。算清楚防护费和服的生命周期，避免恐慌消费。

5. 保留证据并联系机房
   流量图、开始时间、目标端口、采样报文特征发给机房，比只说「被攻击了」有用。问清临时清洗、换高防 IP 的价格与时长再切。

预案附件：和机房说话的清单

准备好：机器 IP、攻击大致开始时间、入向带宽峰值、游戏端口与协议、是否已换 IP、业务是否可接受短时中断。部分机房提供临时清洗，注意时限到了是否自动恢复裸奔。若决定下高防，提前确认游戏协议是否在清洗设备兼容列表里——UDP 游戏被误清洗成「能 ping 不能玩」的案例并不罕见。

心态写进页脚

安全有时是产品决策。好友专服用 VPN，公开服买防护，都是正当选择；不选「既要公开招人又要零成本永不宕」的幻想。运营中期若从熟人局变成公开招人，矩阵要重选——架构跟着产品走，而不是贴一张过期的「我们很安全」标语。

预案每半年过一遍：备用 IP 是否还有效、备份能否在新机器拉起、群公告模板是否还在、机房工单渠道是否仍畅通。圣诞写这份文档的目的，是让下次流量图飙红时，手里有顺序，而不是只有焦虑。选项矩阵贴在文档开头，应急顺序贴在中间，联系机房的话术放在附件——三页纸，胜过十次事后复盘里的「早知道」。