Hetzner是德国知名的服务器托管商，凭借极低的机器价格和不限流量的大带宽方案，在国内开发者圈子里热度一直不低。不过便宜归便宜，一台远在欧洲的机器，到国内公网的延迟到底表现如何，直接决定了它适合跑什么业务。本文基于德国法拉克福机房（FSN1）和芬兰赫尔辛基机房（HEL1）的实际测试数据，详细分析Hetzner到国内三大运营商网络的延迟水平，并给出针对性的优化思路。
测试环境与方法说明
本次测试选取了两台Hetzner云服务器，配置均为最入门的CX22（2核2GB内存），系统为Debian 12，机房分别位于德国法拉克福和芬兰赫尔辛基。测试机所在位置为国内华东地区，出口覆盖电信、联通、移动三个运营商网络。延迟测试主要使用ping和mtr两个工具，前者统计纯网络往返时间，后者用于观察路由跳数和每一跳的质量。
测试时间选择在工作日晚高峰（20点至22点）和非高峰时段（凌晨3点至5点）分别进行，每个目标连续ping超过1000个包后取平均值和丢包率。这样做的目的是排除单次测试的偶然性，同时观察国际链路在高峰期的拥堵情况。需要说明的是，延迟数据会随国际出口波动而变化，本文数据仅供参考，实际体验建议 readers 在购买前利用Hetzner官方提供的测速地址自行验证。
常用的测试命令如下：
# 使用ping持续测试延迟 ping -c 1000 hetzner.example.ip # 使用mtr观察完整路由路径与丢包情况 mtr -rwzb -c 200 hetzner.example.ip
mtr的参数中，-r表示报告模式，-w表示宽格式输出，-z显示ASN自治域编号，-b同时显示IP和主机名，这些信息对判断流量走了哪条线路非常关键。
实测延迟数据分析
从整体数据来看，Hetzner德国机房到国内公网的平均延迟在280毫秒到330毫秒之间，芬兰机房略好一些，平均在260毫秒到300毫秒之间。这个差距主要源于地理位置和回程路由走向：芬兰到国内的流量通常会经过俄罗斯方向或北欧线路进入国内，物理路径相对靠北，而德国流量多数走传统的欧洲骨干网经中东或俄罗斯转接。
分运营商来看，差异比较明显。移动网络的表现最好，晚高峰平均延迟约260毫秒，丢包率基本可以控制在1%以内，这是因为移动的国际出口（CMI）与欧洲多家运营商有直连对等互联。电信用户延迟最高，晚高峰普遍在320毫秒以上，高峰期丢包率有时会上升到3%到5%，走的是传统163骨干网出口，拥堵较为常见。联通居中，平均延迟300毫秒左右，AS4837线路白天表现稳定，晚高峰质量有所下降。
下面是一次典型测试的汇总数据：
| 目标机房 | 运营商 | 平均延迟 | 丢包率 |
|---|---|---|---|
| 德国FSN1 | 电信 | 325ms | 3.2% |
| 德国FSN1 | 联通 | 302ms | 1.8% |
| 德国FSN1 | 移动 | 271ms | 0.6% |
| 芬兰HEL1 | 电信 | 305ms | 2.7% |
| 芬兰HEL1 | 移动 | 256ms | 0.4% |
需要强调的是，丢包率对实际体验的影响往往比延迟更大。一个320毫秒但不丢包的链路，用来做SSH终端操作是完全流畅的；而一个280毫秒但丢包3%的链路，打开网页都会有明显的卡顿感。因此评估Hetzner是否可用，不能只看延迟数字，还要看丢包和抖动情况。
回程路由走向对延迟的影响
同样是从德国到国内，为什么不同运营商的体验差别这么大？关键在于回程路由。Hetzner自身的网络（ASN为AS24940）与国内运营商没有直连，流量需要经过中间转接商进入国内。去程和回程可能走完全不同的路径，这就是所谓的非对称路由。
通过mtr的ASN信息可以观察到，到电信的回程流量经常经过Telia、Cogeco或者Level3这类国际一级运营商转接进入163骨干网，这条路径在晚高峰非常容易拥堵。而移动方向不少流量走CMI（中国移动国际）的直连节点，路径更短更干净。这就是同样的机器，不同运营商用户体感差异巨大的根本原因。
另外要注意路由的绕行问题。部分时段芬兰机房的回程会绕行美国西海岸再进入国内，延迟直接飙到350毫秒以上。这种绕行通常是临时性的路由调整，遇到时不必过于紧张，可以通过持续观察mtr确认是否恢复。如果是长期绕行，可以考虑更换机房或者使用中转方案。
降低延迟的实用优化方案
第一个方案是在国内方向前置CDN。如果你的业务是网站或者API服务，将静态资源甚至动态内容通过国内CDN节点分发，欧洲源站的延迟就被屏蔽在用户视角之外了，用户实际访问的是国内边缘节点，延迟可以降到50毫秒以内。这是成本最低、效果最明显的做法。
第二个方案是启用BBR拥塞控制算法。BBR对高延迟高丢包链路的吞吐提升非常显著，尤其适合Hetzner这种长肥管道场景。开启方法很简单，编辑系统配置后重启即可生效：
# 查看当前拥塞控制算法 sysctl net.ipv4.tcp_congestion_control # 启用BBR echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf sysctl -p # 验证是否生效 lsmod | grep bbr
第三个方案是加中转。在延迟较低的节点（例如日本、新加坡或香港的中转服务器）做流量中继，国内用户先到中转节点，再由中转节点走优质线路到Hetzner。这样国内段的延迟可以控制在100毫秒以内，后端虽然总延迟变化不大，但丢包和抖动会明显改善，TCP重传减少后实际传输速度往往能提升数倍。
总结与选型建议
Hetzner到国内的物理距离决定了延迟下限，280毫秒左右的往返时间是光速和光纤路由决定的硬约束，任何优化都无法突破这个底线。因此它不适合对实时性要求极高的场景，比如实时游戏服务器、视频会议或者需要低延迟主从同步的数据库。
但它非常适合对延迟不敏感但对带宽和流量敏感的业务，例如个人网盘、下载站、爬虫节点、离线计算、备份存储、科学计算集群等。这些场景下，Hetzner不限流量的大带宽加上极低的机器价格，性价比在国内能买到的海外服务器里几乎无出其右。结合CDN、BBR和中转优化后，跑网站服务也是可行的。如果你的用户群体主要使用移动网络，体验会明显更好一些。