游戏服务器用VPS怎么选：延迟与防护

一、延迟的真相：不是数字越小越好

游戏服务器用VPS 选型时，第一个指标几乎所有人都写延迟。但延迟这个数字如果只用一次 ping 来测，基本等于没测。

延伸对照：interserver 的公开机型与线路说明，可结合本节的判断标准自行核对。

ping 测的是 ICMP 回包的往返时间，而真实游戏客户端走的是 UDP 游戏协议，服务器要在收到包后做逻辑运算、更新状态、广播给所有客户端再由客户端解码渲染。真实玩家的操作到画面响应的完整链路，比 ping 多了好几个处理环节。所以一条 30 ms 的线路，游戏里的手感可能相当于 60 ms，ping 完全看不出来。

更重要的是延迟的稳定性。游戏玩家真正敏感的是抖动，也就是延迟的波动。一个稳定 80 ms 的服务器，玩家的感受是「网速一般但能玩」；一个延迟在 30 到 200 ms 之间来回跳的服务器，玩家的感受是「这服务器卡」。抖动在 30 ms 以上时玩家会明显感觉操作黏手，在 80 ms 以上时开始有明显的输入延迟感。

影响抖动的最大因素是共享网络的排队。同一个机房里的邻居如果在跑挖矿或者下载，你的延迟就会跟着抖。这就是为什么同样标称延迟的机器，实际手感可能天差地别。

测延迟的正确做法是装一个 ICMP 之外的工具，在游戏高峰时段连续测几个小时，看的是 P95 和 P99 而不是平均值：

# 用 mtr 看逐跳路径和每一跳的丢包与抖动，比 ping 更能定位问题
mtr -rw -c 100 -i 1 你的服务器地址

# 测 TCP 握手延迟（更接近真实建连）
for i in $(seq 1 20); do
  curl -o /dev/null -s -w "握手:%{time_connect}s 首字节:%{time_starttransfer}s\n" "http://你的服务器地址/"
  sleep 2
done

判定标准是：平均值控制在 80 ms 以内，P95 不超过 120 ms，P99 不超过 200 ms，且测试期间不出现明显的丢包尖峰。超过这个区间就不要抱侥幸心理，因为玩家会用脚投票。

二、tick 频率和 CPU：游戏服到底吃配置吗

游戏服务器用VPS 的 CPU 需求，取决于两件事：服务器的 tick 频率，以及每个 tick 里要处理多少逻辑。这两件事决定了为什么同样玩法的服，有的 2 核就够，有的 8 核还在卡。

延伸对照：itldc 的公开机型与线路说明，可结合本节的判断标准自行核对。

主流竞技游戏的服务端 tick 通常是每秒 30 次到 64 次。Minecraft 类沙盒服务器常见 20 tick，也就是每秒计算 20 次世界状态。tick 越高手感越顺，但 CPU 消耗几乎线性上升：一个 20 tick 的服在 60 tick 下跑，CPU 占用会翻到三倍左右。

关键的一点是 tick 预算必须留余量。理想状态下一个 tick 的计算时间应该远小于 tick 间隔。20 tick 意味着每 tick 只有 50 毫秒，而实际应该让单 tick 耗时控制在 5 到 10 毫秒以内，这样才能扛住偶尔的 GC 停顿或者磁盘抖动导致的尖峰。如果单 tick 已经用到 25 毫秒，玩家就会感觉到周期性的卡顿。

不同类型的游戏服对资源的分布完全不同，下面这张表是常见的经验区间：

游戏类型	tick 频率	CPU 占用特征	内存占用	带宽特征
方块沙盒类	20 tick	吃单核主线程，方块越多越吃	每玩家数百 MB	低，KB 每秒级
竞技射击类	64 tick	吃单核，回放和物理运算重	每玩家数十 MB	中，KB 到 MB 每秒
竞速模拟类	60 tick	物理插值吃 CPU	每玩家百 MB 级	低但延迟敏感
RPG 类	30 tick	AI 寻路吃 CPU	每玩家百 MB 级	低
私服综合类	20 到 64 tick	插件和脚本吃 CPU	插件多时翻倍	中

从表里能读出两条对选型直接有用的结论。第一，几乎所有游戏服的主逻辑都是单线程的，也就是说「多核」对游戏服的价值远低于对网站服的价值。一台 8 核机器和一台 4 核机器跑同一个游戏服，实际表现差距可能只有百分之几，因为主线程还是一根。选游戏服时，CPU 主频、单核性能和内存容量比核心总数重要得多。

这里还要补一个容易被绕进去的推理：单线程不等于单核慢就一定差。游戏服的运算单位通常是几十毫秒级的浮点计算和向量运算，这些任务对指令集缓存和单核 IPC 敏感，而对并行度不敏感。所以同一款游戏在同一台机器上，主线程跑到百分之九十占用时，如果还有多个空闲核，它也不会自动帮你分担——除非服务端本身做了多线程化。所以别指望「买八核跑四核的量」，那不成立。

第二，内存比 CPU 更容易成为瓶颈。游戏服加载地图和玩家数据都在内存里，内存不足会触发换页，磁盘换页会直接造成几十毫秒的卡顿，这个延迟比 CPU 满载还致命。所以选型时内存宁可多给一档。

判断内存够不够的经验公式是：单人基础占用乘以峰值在线人数乘以一点三的余量，加上地图和插件的固定开销。以沙盒类为例，单人基础占用按一百五十 MB 估，五十人同时在线约七点五 GB，加上地图和插件两 GB，十二 GB 内存是合理起点，十六 GB 会更从容。这个估算只是起步，真实的内存曲线要跑起来看。

# 看进程实际占用的内存和线程数
ps -o pid,nlwp,rss,vsz,cmd -C 你的游戏服务端程序名

# 用 top 按线程看，确认是哪个线程吃满 CPU
top -H -p 你的游戏服务端PID

# 实时看系统层面的上下文切换，切换过多说明调度压力或内存吃紧
vmstat 1 10

如果 vmstat 输出里的 cs（上下文切换）持续很高，同时 si 和 so（非自愿换页）不为零，那基本可以确定是内存不足或磁盘太慢。

三、带宽类型：UDP、TCP 和端口是三件事

游戏服务器用VPS 的带宽需求看起来很小，一个玩家也就几十 KB 每秒，但带宽这件事有三个容易混淆的维度，选错任何一个都会直接导致「连不上」。

延伸对照：iwebfusion 的公开机型与线路说明，可结合本节的判断标准自行核对。

第一个维度是协议。绝大多数现代游戏走 UDP，因为 UDP 没有握手和重传机制，开销小、延迟低。但 UDP 在公网上有丢包问题，而且很多机房默认会做 UDP 限速或者干脆屏蔽。所以买机器时必须确认两件事：商家是否放行 UDP，以及你的游戏端口有没有被限制。如果商家只给你 TCP，那你可以用 OpenVPN 或者 frp 之类的方案把 UDP 包封装进 TCP 隧道，但这样会引入 TCP-over-TCP 的经典问题，丢包时延迟会剧烈抖动，体验明显变差。

第二个维度是端口范围。部分商家为了防滥用，会把高端口段（比如 30000 以上）或者一组随机端口屏蔽掉，而某些游戏服务端默认就监听高位端口。买之前查清楚你的游戏默认用什么端口。

第三个维度是带宽本身。游戏服的带宽需求确实不高，但要注意一个容易被忽略的点：开服时的资源下载。玩家第一次进服要下载所有材质、模型、地图文件，一个几十 GB 的整合包在开服首日会被几十个玩家同时拉取，这时候的带宽需求和游戏内运行完全不是一个量级。开服前用限速工具控制一下，或者在开服公告里写明分批下载，能避免开服当天的带宽账单失控。

# 检查 UDP 端口是否被商家屏蔽，从本机往目标机器发 UDP 包
nc -zvu 目标地址 25565

# 看本机游戏服监听的端口和协议
ss -ulnp | grep 游戏服务端进程名

# 开服期间用 tc 限制单 IP 下载速率，防止个别玩家吃满带宽
tc qdisc add dev eth0 root handle 1: htb default 10
tc class add dev eth0 parent 1: classid 1:10 htb rate 2mbit ceil 2mbit

关于带宽的一句话结论是：游戏服对带宽的绝对需求低，但对带宽的突发容忍度更低。宁可带宽标称小一点但线路稳定，也别为了看起来大买一个共享严重的高带宽口。

还有一条和带宽直接相关的经验：游戏服的带宽需求要按峰值在线人数乘以单玩家流量再乘以一点五的突发系数来估算，而不是按平均在线人数。原因是开服活动或者版本更新时，在线人数会在十几分钟内翻几倍，而带宽计费的商家如果采用固定带宽模式，超出部分可能直接限速。限速对游戏服是双重打击，既有带宽又有延迟。建议在采购时按活动期的峰值人数做预算，平时用不满的部分就是预留的安全余量，这比事后被限速划算得多。

四、NAT 端口与独立 IP：能不能开服的关键前提

游戏服务器用VPS 最常见的翻车点不是配置不够，而是 IP 类型不对导致玩家连不上。购买之前必须搞清楚商家给你的是独立公网 IP 还是 NAT 小鸡。

延伸对照：justg 的公开机型与线路说明，可结合本节的判断标准自行核对。

独立公网 IP 是完整的、只属于你一个人的地址，可以直接接受入站连接，可以做域名解析指向，可以在任何地方被识别为同一个主机。NAT 小鸡则是通过端口映射的方式共享宿主机的一个公网 IP，你拿到的是一个内网地址加上若干映射端口，外部访问必须带上商家指定的端口号。

NAT 小鸡的问题非常实际。第一，你的端口号是被映射过的，游戏客户端的默认端口配置通常要手动改成宿主机映射出来的那个高端口，很多玩家不会弄，于是根本连不上。第二，端口数量有限，通常只有几十个，如果你要开多个实例、分多个服务器、还要给管理面板和网站留端口，很快就不够用。第三，在游戏平台（Steam 社区服务器、Battle.net 好友对战列表）上做公开匹配时，NAT 地址无法被平台正常识别和注册。第四，IP 信誉是共享的，同一台宿主机上其他用户做过什么会影响你的封禁情况。

独立 IP 的价格通常比 NAT 高，这是合理溢价，因为资源是独占的。具体价格以各商家官网当日报价为准，但判断标准是明确的：开公开服、需要进平台匹配列表、或者要长期稳定运营的，必须买独立 IP；纯粹自己和几个朋友联机玩、或者做开发测试，NAT 小鸡够用。

# 检查自己拿到的到底是独立 IP 还是 NAT 映射
ip addr show | grep "inet "
# 对比：你的网卡上应该是公网地址，NAT 小鸡这里会是 10.x / 172.16-31.x / 192.168.x
curl -s ifconfig.me

如果输出地址和网卡地址不一致，说明你拿到的就是 NAT 映射。还要确认一件事：商家给你的映射端口是否覆盖你游戏需要的端口范围，能不能要求他们指定一个固定的对你友好的端口号。

五、DDoS 防护：搞清楚保护边界再付钱

游戏服务器用VPS 被人攻击是常态，不是意外。公开开服必然遇到扫描、恶意抓包、UDP 反射放大，甚至针对性的流量攻击。所以防护能力必须作为选型的硬指标。

延伸对照：racknerd 的公开机型与线路说明，可结合本节的判断标准自行核对。

防护要分清三层，混为一谈是最常见的误判。第一层是被攻击时的自动清洗，也就是常说的高防 IP 或流量清洗服务。它的逻辑是流量先进到清洗中心，超过阈值的部分被识别并丢弃，正常流量转发到你的机器。这种防护按流量或按 IP 单独收费，通常带宽阈值在几 Gbps 到几十 Gbps 之间，具体阈值和报价以各商家官网当日报价为准。关键是要问清楚清洗阈值是多少，超过阈值之后是丢弃还是计费继续。

第二层是基础清洗和空路由。大部分 VPS 默认带一点免费的基础防护，通常是几 Gbps 的自动拉黑。这个量级能挡住大部分业余攻击和常见的 UDP 反射，但挡不住持续的定向攻击。

第三层是被动防护，也就是你的机器自身不被打挂。这包括内核层面的 SYN flood 防护、连接数限制、以及及时打系统补丁。很多所谓的高防机器其实只是在前面挂了一层薄薄的清洗，自己的机器照样会被应用层攻击打死。

游戏服还有一个特殊的攻击面：游戏协议本身的开销放大。UDP 协议没有握手，攻击者可以用很小的上行流量换取很大的下行流量，典型的放大反射可以达到几十倍。所以选防护时必须问一句：是否包含 UDP 反射放大防护，只防 TCP SYN 的话对游戏服意义有限。

# 查看是否有可疑的 UDP 反射源，统计 UDP 包最多的来源
tcpdump -n udp -c 2000 | awk '{print $3}' | sort | uniq -c | sort -rn | head

# 限制单 IP 的连接与发包速率，抑制反射放大
iptables -A INPUT -p udp --dport 25565 -m connlimit --connlimit-above 20 --connlimit-mask 32 -j DROP
iptables -A INPUT -p udp --dport 25565 -m limit --limit 50/s --limit-burst 100 -j DROP

自查防护是否到位的办法是看日志里有没有大量来自陌生 IP 的游戏协议包，以及看机器有没有出现非预期的流量峰值。先扫一遍开放端口，把不必要的服务关掉，本身就是最有效的防御。

六、机房位置：国内玩家和海外玩家的取舍

游戏服务器用VPS 的机房位置，直接决定了玩家体验的天花板。国内玩家占绝大多数的服，位置是选型的第一变量。

延伸对照：spinservers 的公开机型与线路说明，可结合本节的判断标准自行核对。

主流选择大致有三类。第一类是香港、日本、新加坡这类亚洲近距离节点，到中国大陆的延迟一般在 40 到 90 ms 之间，是目前国内玩家访问海外游戏服的主流选择。第二类是美西洛杉矶，延迟通常在 140 到 180 ms 之间，受物理距离限制较大，但在低峰时段和特定运营商线路上体验尚可。第三类是欧美其他节点，延迟普遍在 200 ms 以上，只适合以欧美玩家为主或者纯挂机型的服。

需要注意线路质量比地理距离更重要。同样在香港，走优化线路和走普通国际线路，丢包率可以差出几倍。判断线路质量看两个指标：晚高峰时段（国内一般 20:00 到 23:00）的丢包率，以及是否走 CN2 之类的优化通道。商家宣传的线路类型最终要用实测来验证。

国内玩家还有一个绕不开的现实：机房位置和带宽决定了晚高峰的实际速度，而晚高峰恰恰是玩家最多的时段。所以选型时必须专门在晚高峰测一次速度，不能用白天的测速结果做决策。

# 晚高峰测速：测下载、测丢包、测抖动，缺一不可
# 丢包率
ping -c 100 -i 0.2 你的服务器地址 | tail -3
# 抖动
# mtr 输出里各跳的丢包和平均延迟，重点看末跳
mtr -rw -c 50 你的服务器地址
# 实际下载速度
curl -o /dev/null -s -w "速度:%{speed_download}B/s 总耗时:%{time_total}s\n" "http://你的服务器地址/100MB.bin"

# 服务器端看网卡丢包和错误包
ip -s link show eth0 | grep -A2 "RX:" 
netstat -su | grep -E "packet receive errors|overflow"

服务器端如果出现 receive errors 或者网卡 overflow，说明流量已经在服务器入口处被挤爆了，这时候再谈配置也没有用，只能往上加带宽或者加防御。

七、成本怎么算：游戏服的月账其实很薄

游戏服务器用VPS 的成本结构和网站完全不同，网站服的成本大头是带宽和流量，游戏服的成本大头是配置和防护。而且带宽往往只占很小一块，这会让很多人一开始的预算估算完全失准。

延伸对照：zenlayer 的公开机型与线路说明，可结合本节的判断标准自行核对。

按一个月付的常见结构列一下，成本大致是这样分布的：

成本项	占比特征	说明
服务器月租	主要成本	按核数内存档位，具体以各商家官网当日报价为准
DDoS 防护	次要成本	基础防护常含在月租内，超阈值清洗单独计费
额外 IP	按需	多服或多端口映射时才需要
带宽	占比很低	游戏运行流量小，开服首日是例外
备份与快照	可选	存档丢失的代价往往高于快照费用

所以真正的选型结论是：与其在带宽上省钱，不如把预算花在 CPU 主频和内存上。游戏服最忌讳的是「配置看着大但单核不行」或者「内存给少了一档导致换页」。

还有一个时间维度容易被忽略。游戏服的在线人数随活动周期起伏，开服活动期人数翻几倍，平常期又很闲。所以有两种策略：一种是按峰值配机器，代价是平时浪费；另一种是平时用小机器，活动期临时扩容到高配，代价是扩容过程有几分钟不可用，但能省下大部分月费。服务器商家的弹性扩容功能是否存在、扩容需要多久、扩容后 IP 会不会变，这三点要在买之前问清楚，因为 IP 变了意味着玩家要重新连。

存档备份是另一笔隐性成本。游戏服的存档文件是所有玩家投入的载体，一旦误删或者损坏，服基本就废了。备份方案和带宽成本无关，只占很小一块，但必须做。

# 用 cron 每小时打一次存档快照，保留 7 天
0 * * * * tar -czf /backup/world-$(date +\%Y\%m\%d-\%H).tar.gz -C /srv world/ && \
  find /backup -name "world-*.tar.gz" -mtime +7 -delete

# 校验备份文件是否完整，避免备份了但其实是坏的
gzip -t /backup/world-最新.tar.gz && echo "备份校验通过"

八、几个踩坑复盘

这一节把游戏服选型过程中最常见的翻车原因集中列出来，每一条都对应着真实的技术原因而不是运气。

延伸对照：cloudcone 的公开机型与线路说明，可结合本节的判断标准自行核对。

第一个坑是买了 NAT 小鸡还以为能让朋友直接连。实际上朋友需要改端口，Steam 的好友列表里也搜不到这个服，最后变成每次都要发一串带端口的地址。翻车的原因是以为「能连上就等于能用」，忽略了 NAT 在连接之外还有一整套限制。

第二个坑是 CPU 核数买多但单核不行。同价位的机器，CPU 主频可能差出一倍，而游戏服主逻辑是单线程的，核数再多也帮不上忙。翻车的原因是按核数比价。

第三个坑是内存给少，开服第一天人少没事，人一多开始换页，卡得没法玩。翻车的原因是没有按「每玩家内存占用乘以预期在线峰值」来算，而是按开服人数加了一点余量。

第四个坑是买了大带宽共享口，晚高峰延迟飘到三百毫秒以上。翻车的原因是白天测速看着很快，没有在晚高峰复测。

第五个坑是防护没问清是只防 TCP SYN。游戏服被 UDP 反射攻击一波就满血，而商家宣传的「高防」可能只覆盖 TCP。翻车的原因是只问了「有没有防护」，没问「防什么协议」。

第六个坑是开服当天没有限制下载带宽，一百个玩家同时下整合包，直接把带宽打满并且账单爆炸。翻车的原因是只考虑了游戏内流量。

第七个坑是机器上留着默认的 SSH 密码和没关的管理面板。扫描器一天扫几百万个 IP，你的机器只要端口暴露就会被找到并尝试爆破。翻车的原因是买来当天没有做安全加固。

# 上线前的最小安全加固检查清单
# 1. 禁止密码登录，只用密钥
sed -i 's/^#*PermitRootLogin.*/PermitRootLogin prohibit-password/' /etc/ssh/sshd_config
sed -i 's/^#*PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
# 2. 换掉默认端口
sed -i 's/^#*Port 22/Port 你的自定义端口/' /etc/ssh/sshd_config
# 3. 只放行游戏端口和 SSH
ufw default deny incoming && ufw allow 你的自定义端口/tcp && ufw allow 25565/udp && ufw enable
# 4. 确认对外只暴露必要端口
ss -tulnp | awk 'NR>1 {print $1, $5}'

九、按场景选：新手、预算紧、要稳定

游戏服务器用VPS 落到具体购买决策上，按三种典型需求给路径。

延伸对照：digitalocean 的公开机型与线路说明，可结合本节的判断标准自行核对。

新手第一次开服，预算有限，主要目的是体验一遍从买机器到拉朋友进来玩的全流程。选择建议是：靠近玩家的亚洲节点（香港或日本）、独立 IP、基础防护够用的入门配置、内存给到玩得动的下限。不需要买高防套餐，因为刚开服没什么人攻击；不需要买大带宽，因为游戏本身用不了多少。这一档的核心目标是让流程跑通。

预算紧到要精算每一块钱的时候，策略要反过来：优先保证网络质量，其余全部压缩。选一个延迟低但配置普通的套餐，靠精简服务端参数和优化 tick 来跑。优化方向包括降低实体加载范围、限制视距、关闭不必要的实体和红石逻辑、减少插件数量。这些手段对内存和 CPU 的影响往往是数量级的，比换机器有效。具体可调参数以所用服务端版本的实际配置文件为准。同时把存档备份做好，压缩存储空间，把不用的日志关掉。

要求长期稳定运营的情况下，判断标准要提高到四个硬指标：晚高峰 P95 延迟在 120 ms 以内且无周期性抖动、防包含 UDP 反射放大、内存有至少两倍峰值余量、IP 信誉干净且有独立段。配置上不追求核心多，而是追求单核性能强、内存充足。防护和线路的预算优先级要排在配置之前，因为线路和防护的短板是无法用配置补的。

不管哪种场景，验证环节都是一样的：先按月付买一台，在真实的晚高峰跑一周，用 mtr 和服务端日志收集数据，确认达标后再考虑长约。如果商家支持从 NAT 迁到独立 IP 或者换机房，提前问清楚迁移流程和 IP 变更的代价。

十、常见问题

游戏服务器用VPS 几核几 G 内存够用？ 取决于游戏类型和人数，不是核数越多越好。以方块沙盒类为例，20 tick 下 20 人以内通常 4 核 8G 起步，50 人以上建议 8 核 16G 起；竞技射击类 32 人左右 4 核 8G 通常够。判断标准是跑起来之后用 top -H 看主线程有没有跑满，内存有没有接近上限。

延迟多少算能玩？ 看 P95 不看平均。平均值 60 ms 但 P95 冲到 250 ms 的服，玩家一样会觉得卡。稳态控制在 80 ms 以内、P95 不超 120 ms 是比较舒服的区间；竞技类要求更严，120 ms 以上的手感差异会很明显。

独立 IP 和 NAT 小鸡到底差在哪？ 差在能不能被正常访问。NAT 小鸡要手动改端口、游戏平台匹配列表里注册不了、端口数量有限。朋友联机可以用 NAT，开公开服、要在平台里被搜到、或者要长期做口碑的必须独立 IP。

DDoS 防护买多贵才够？ 看两个参数：清洗阈值是多少（单位 Gbps），以及是否包含 UDP 反射放大防护。对游戏服来说，只防 TCP SYN 的防护价值有限。要问清楚超出阈值之后是丢弃流量还是继续计费。

能不能用 UDP 的机器跑 TCP 游戏？ 可以，服务端本身支持 TCP，但要意识到 TCP 的重传机制在高丢包线路上会把延迟放大，体感明显差于 UDP。如果商家屏蔽 UDP 又没有优化线路，用 TCP 会有明显代价。

开服当天带宽被玩家下载资源打满怎么办？ 提前用 tc 给单 IP 限速，或者在公告里写明分批下载。游戏运行本身流量很小，真正的峰值出现在开服首日的资源分发阶段，这个必须单独预案。

换机房或者升级配置，IP 会变吗？ 取决于商家。多数商家同机房升级配置 IP 不变，跨机房迁移则基本会变。购买前直接问商家这条规则，因为 IP 变了意味着所有玩家的收藏、Steam 列表记录都要重来。

服务器上跑几个游戏服实例会不会互相影响？ 会，而且影响方式很隐蔽。多个实例共用一个核时，主线程会互相抢 CPU，表现为所有人的延迟同时上升。所以一台机器放多个实例时，要么保证实例数不超过物理核数，要么给每个实例做 CPU 亲和绑定。用 taskset 固定每个实例的核，能显著减少互相干扰。