法兰克福 VPS 托管适合哪些项目？

适合在法兰克福使用 VPS 托管的项目

法兰克福 VPS 托管适合用户位于德国、更广泛的德语市场或欧盟各地的项目。法兰克福是欧洲网络互联并直接交换流量的重要节点之一，因此部署在当地的服务器通常可在几十毫秒内到达欧洲大陆的大部分地区。如果您的用户主要位于北美，无论服务器性能多快，欧洲服务器对他们来说仍会响应较慢，因为地理距离决定了最低延迟，优化无法消除这一限制。

选择部署位置时，需要分别回答两个问题。将这两个问题混为一谈，容易导致错误决策。第一个问题是用户位于哪里，这涉及距离和往返时间。第二个问题是数据可以存储在哪里，这涉及法律和合同要求。对于面向欧洲用户的项目，法兰克福在第一个问题上具有明显优势。对于第二个问题，法兰克福只能解决其中一个具体问题，不能解决其他合规事项。

为什么法兰克福的网络连接如此发达？

法兰克福设有 DE-CIX（德国商业互联网交换中心）。DE-CIX 是 IXP（互联网交换点），按峰值流量和接入网络数量计算，均属于全球规模最大的互联网交换点之一。IXP 是数据中心内的共享交换网络。各个独立网络可以在这里互联，而不必支付更大的网络来承载彼此之间的流量。DE-CIX 会在其官方网站发布当前流量统计数据。这些数字会变化，因此应以该网站的数据为准，不要依赖文章中复制的某个数值。

实际影响取决于路径，而不是流量总量。当您的网络提供商和访客的 ISP（互联网服务提供商）都接入同一个交换点时，两者之间的流量只需在该交换点经过一个路由跳数。当两者不在本地互联时，流量必须先到达同时承载这两个网络的第三方网络，而该网络最近的交接点可能位于其他国家。两个德国网络如果通过阿姆斯特丹或伦敦交换流量，就要为额外距离各承担一次，分别对应两个方向。网络工程师将这种现象称为 tromboning。这通常就是附近服务器测得的网络距离却很远的原因。

您可以直接查看路径，而不是凭经验判断。从您关注的网络向服务器运行 mtr，然后查看反向 DNS 中的跳数名称。路由器主机名通常包含 IATA 机场代码，因此跳数名称中的 fra 表示法兰克福，ams 表示阿姆斯特丹，lhr 表示伦敦。从德国消费者网络连接到德国服务器的路径中，如果中间出现 lhr，就能准确说明额外的几毫秒延迟经过了哪里。

您的用户距离 Frankfurt 有多远？

光纤中的光速约为真空光速的三分之二，接近每秒 200,000 千米。往返传输需要经过两次路径，因此，距离为 d 千米时，最快的往返时间是 d/100 毫秒。这是理论下限，非常有参考价值，因为任何方案都不可能超越它。

[
  {
    "label": "Zurich",
    "distance_km": 304,
    "min_rtt_ms": 3.0
  },
  {
    "label": "Amsterdam",
    "distance_km": 365,
    "min_rtt_ms": 3.7
  },
  {
    "label": "Berlin",
    "distance_km": 424,
    "min_rtt_ms": 4.2
  },
  {
    "label": "Paris",
    "distance_km": 479,
    "min_rtt_ms": 4.8
  },
  {
    "label": "Milan",
    "distance_km": 519,
    "min_rtt_ms": 5.2
  },
  {
    "label": "Vienna",
    "distance_km": 600,
    "min_rtt_ms": 6.0
  },
  {
    "label": "London",
    "distance_km": 640,
    "min_rtt_ms": 6.4
  },
  {
    "label": "Warsaw",
    "distance_km": 903,
    "min_rtt_ms": 9.0
  },
  {
    "label": "Stockholm",
    "distance_km": "1,197",
    "min_rtt_ms": 12.0
  },
  {
    "label": "Madrid",
    "distance_km": "1,419",
    "min_rtt_ms": 14.2
  },
  {
    "label": "New York",
    "distance_km": "6,206",
    "min_rtt_ms": 62.1
  }
]

这些数据根据两地直线距离计算得出，并非实测结果。最后一列表示物理条件允许的最佳情况。实际测量结果通常是理论下限的 1.5 到 2 倍，因为光纤会沿道路和河谷铺设，而不是沿大圆航线铺设；此外，路径上的每台路由器都会增加少量转发和排队延迟。

Berlin 距离 Frankfurt 424 千米，理论下限为 4.2 毫秒。Madrid 距离这里 1,419 千米，理论下限为 14.2 毫秒，也是从这里出发到 EU 内最远的角落。New York 距离这里 6,206 千米，理论下限为 62.1 毫秒。因此，面向跨大西洋用户时，机房位置是架构决策，而不是调优问题。

一次慢速往返会让页面加载付出什么代价？

一次往返通常不止一次往返。建立 HTTPS 连接时，TCP（传输控制协议）握手需要一次往返，TLS（传输层安全）1.3 握手还需要一次往返。随后发送请求，在响应的第一个字节返回前还需要第三次往返。TLS 1.2 则会增加到第四次。如果 DNS（域名系统）查询结果尚未缓存，至少还要增加一次往返，而且目标是另一台服务器。

[
  {
    "label": "User in Frankfurt",
    "rtt_ms": 5,
    "first_byte_ms": 15
  },
  {
    "label": "User in Warsaw",
    "rtt_ms": 20,
    "first_byte_ms": 60
  },
  {
    "label": "User in Madrid",
    "rtt_ms": 30,
    "first_byte_ms": 90
  },
  {
    "label": "User in New York",
    "rtt_ms": 90,
    "first_byte_ms": 270
  },
  {
    "label": "User in Singapore",
    "rtt_ms": 170,
    "first_byte_ms": 510
  }
]

这里的往返次数列是根据通往 Frankfurt 服务器的一条合理路径作出的假设，第二列则是据此计算得出的结果：在收到第一个字节前需要三次往返。Frankfurt 的用户需要等待 15 ms。Singapore 的用户往返时间为 170 ms，在浏览器开始绘制任何内容前，需要等待同一响应返回 510 ms。

倍数效应才是关键。RTT（往返时间）每增加 1 ms，在收到第一个字节前大约会增加 3 ms 的等待时间，后续仍会继续产生影响。HTML 指定一个样式表，样式表又指定一个字体，而发现这些资源中的每一项，都需要在同一连接上再进行一次往返。距离增加几百毫秒后，原本感觉即时打开的页面会变得缓慢，尽管服务器执行的工作完全相同，耗时也完全相同。

这也说明了 CDN（内容分发网络）能解决什么问题，以及不能解决什么问题。由靠近用户的缓存提供的静态文件可以跳过较长的网络路径。需要向数据库查询数据的登录后控制面板则不行：该请求仍需跨越完整距离两次。将源站部署在登录用户附近，是缓存无法替代的部分。

如何从用户所在位置测量？

请从目标网络中的一台机器运行以下命令。最好使用服务所在国家/地区的家庭或办公网络连接。从其他数据中心中的另一台服务器测量，只能反映数据中心之间的路径，不能反映用户的实际情况。以下命令示例需要您自行运行；只有您实际测得的延迟数据才值得据此采取措施。

ping -c 20 your-server.example.com

摘要行显示 rtt min/avg/max/mdev = ...。读取 avg 了解典型情况，读取 mdev 了解抖动，即数据包之间的变化。正常的 avg 如果 mdev 较高，说明路径不稳定。与平均延迟略高相比，这种情况对 SSH 或语音等交互式工作造成的影响更大。

sudo apt update && sudo apt install -y mtr-tiny
mtr -rwzc 50 your-server.example.com

-r 输出报告，而不是实时显示；-w 保留完整的长主机名；-z 显示每一跳的 AS（自治系统）编号；-c 50 发送 50 个周期。中间某一跳显示丢包，但最终一跳没有丢包，这属于正常情况，不表示存在故障：许多路由器会限制自身生成的 ICMP 响应速率，但仍能正常转发其他流量。从某一跳开始并持续到后续每一跳的丢包才是真实丢包。

curl -sS -o /dev/null -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://your-server.example.com/

每个字段表示自请求开始以来累计的秒数，因此需要通过相减来读取。time_namelookup 是 DNS。time_connect 减去它就是 TCP 握手耗时，接近一个往返时间。time_appconnect 减去 time_connect 就是 TLS 握手耗时。time_starttransfer 减去 time_appconnect 就是应用自身的处理时间加上另一个往返时间。如果各时间差都很小，而 total 仍然很大，问题就在代码，而不在城市。

如果要测量吞吐量而不是延迟，请在 VPS 上运行 iperf3 -s，在防火墙上开放其端口，然后从客户端运行 iperf3 -c your-server.example.com -R，以测试下载方向。若要从没有机器的地点进行测量，RIPE Atlas 提供分布在欧洲各地的探针。比较两台服务器而不是两个网络时，应使用固定方法，而不是依赖一次性数据；可重复的 VPS 基准测试就是为此准备的。

法兰克福的服务器能让我的项目符合 GDPR 要求吗？

不能。原因需要准确说明。GDPR（《通用数据保护条例》）的适用依据是您处理谁的个人数据，以及您的组织设立在哪里，而不是硬件所在的国家。将服务器迁移到法兰克福不会自动实现合规，在欧盟以外运行服务器也不会自动导致违规。服务器位置只是多个因素之一。

在欧盟或更广义的 EEA（欧洲经济区）内部托管，确实可以避免国际数据传输问题。该法规专门用一章规定将个人数据发送到 EEA 以外的情形，此类传输需要适当性决定或标准合同条款等法律依据。留在法兰克福的数据不会发生传输，因此这一章不适用于这一步。这是真实存在的简化，也是这一做法实际能带来的全部好处。

其他合规工作仍由您负责。您仍需为每个处理目的确定合法依据，为数据库中的人员提供可正常使用的访问权和删除权，制定并实际执行保留期限，采取与风险相匹配的安全措施，并在知悉个人数据泄露后 72 小时内向监管机构报告。您还需要与托管服务提供商签订处理者协议，该协议在德国称为 Auftragsverarbeitungsvertrag 或 AVV。还要注意，如果 EEA 以外的支持人员可以访问法兰克福的服务器，仍可能构成数据传输，因此请确认密钥由谁持有。

德国还在此基础上增加了本国法律要求：联邦 BDSG（《联邦数据保护法》）通过国家规则补充该条例，其中员工数据最容易让人忽视。本文仅提供一般背景信息，不构成法律建议。欧洲数据保护委员会在 edpb.europa.eu 发布官方指南。任何可能产生实际影响的事项，都应咨询合格的专业顾问，而不是只参考教程。

服务器本身需要修改什么？

将系统时钟保持为 UTC（协调世界时），并在应用程序中格式化时间戳。德国实行夏令时，因此当地时间每年会有两次调整，每年10月底会重复出现一个小时。使用当地时间写入的日志会在当晚出现两个 02:30 条目，跨区域关联日志时只能猜测。如果仍希望服务器使用当地时间，请显式设置并检查：

sudo timedatectl set-timezone Europe/Berlin
timedatectl

夏季输出应显示 Time zone: Europe/Berlin (CEST, +0200)，冬季输出应显示 +0100。

默认 C locale 会错误地排列德语文本，因为 C 排序比较原始字节。生成 locale 并查看差异：

sudo locale-gen de_DE.UTF-8
sudo update-locale
printf 'Zebra\nÄpfel\nApfel\n' | LC_ALL=C sort
printf 'Zebra\nÄpfel\nApfel\n' | LC_ALL=de_DE.UTF-8 sort

第一个排序会将 Äpfel 排在 Zebra 之后，因为它在 UTF-8 中的第一个字节高于任何 ASCII 字母。第二个排序会将它放在 Apfel 旁边，这符合德语读者的预期。这一点比看起来更重要，因为 PostgreSQL 和 MySQL 会在创建数据库时固定排序规则，之后更改排序规则意味着必须重建索引。请在加载数据前决定排序规则。

使用德国软件包镜像可以缩短 apt 的运行时间。在 Ubuntu 24.04 中，源配置以 deb822 格式存放在 /etc/apt/sources.list.d/ubuntu.sources，因此应将 URIs: 行修改为 http://de.archive.ubuntu.com/ubuntu/，而不是添加第二个文件。添加第二个文件会产生 Target Packages ... is configured multiple times，即 deb822 重复源错误，并会在问题解决前停止更新。

发布 AAAA 记录。一些德国 ISP 会为用户连接提供 DS-Lite（轻量级双栈）配置。在这种配置下，用户完全没有公网 IPv4 地址，IPv4 流量会经过运营商的转换网关。该网关会增加延迟，并在高峰时段造成拥塞；IPv6 流量则会直接访问外部网络。设置记录后，请检查两条路径：

dig AAAA your-server.example.com +short
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://your-server.example.com/

第二条命令输出 200，表示 IPv6 端到端可用。输出 Could not resolve host 或出现连接错误，表示记录或监听器缺失，使用 DS-Lite 的访客正在走较慢的路径。

不应选择 Frankfurt 的情况

• 您的用户在美国。应从美国提供服务：达拉斯的 VPS 位于美国中部附近，而 纽约的 VPS 托管 是面向美国东海岸用户以及本就需要跨越大西洋的流量的更短路径。
• 您的用户在拉丁美洲。Frankfurt 距离 São Paulo 比距离 New York 更远，因此对于这类用户，巴西的 VPS 才是合理选择。
• 您的数据必须留在欧盟以外的特定国家/地区。加拿大公共部门项目是常见情况，加拿大 VPS 托管真正需要关注的事项介绍了加拿大的数据驻留要求。
• 您运行的是游戏服务器。玩家可以感受到每一毫秒的往返延迟，因此服务器与玩家的距离比其他任何规格都更重要：为游戏服务器选择 VPS将详细说明这一点。

如果您的欧洲用户分布在多个国家/地区，Frankfurt 是稳妥的单一选择。随着业务增长，它仍然可靠，因为您需要访问的网络已经接入该交换中心。在迁移前从用户所在位置进行测量，迁移后再次测量，并保留两组数据。

FAQ

对整个欧洲来说，一台位于法兰克福的 VPS 够用吗？

对大多数项目来说，够用。按直线距离计算，斯德哥尔摩的理论下限为 12.0 ms，马德里的理论下限为 14.2 ms；实际路径的延迟通常约为理论下限的 1.5 到 2 倍，因此几乎整个欧盟到法兰克福这台服务器的延迟都在几十毫秒以内。当你测得某个具体国家确实存在访问问题，或需要故障转移而不是更低延迟时，再增加第二个位置。

在法兰克福托管项目，是否就符合 GDPR？

不符合。GDPR 的适用范围取决于你处理谁的个人数据以及你的设立地点，而不是服务器所在位置。将服务器托管在欧盟，可以免除该链路上的国际数据传输问题，这是实际的简化，也是全部收益。你仍需具备合法处理依据、有效的数据主体权利机制、保留期限、安全措施，在 72 小时内报告数据泄露，并与服务提供商签署处理者协议；该协议在德国称为 AVV。本回答仅提供一般信息，不构成法律建议。

法兰克福和柏林之间的延迟通常是多少？

两座城市相距 424 km，这将往返时间的理论下限设为 4.2 ms。对等互联良好的路径通常测得理论下限的 1.5 到 2 倍。使用来自柏林的连接运行 ping -c 20 your-server.example.com，并读取 rtt min/avg/max/mdev 行中的 avg 值进行确认。结果如果远高于该范围，通常表示流量离开德国后又返回；mtr -rwzc 50 会在跃点名称中显示这一点。

是否应将法兰克福服务器的时区设置为 Europe/Berlin？

通常不应这样做。将系统保持为 UTC，以便日志保持可比，且不会出现时间戳歧义。德国在春季切换到 CEST，在秋季切回 CET；秋季切换的夜间会有一个本地小时出现两次，因此两个不同事件可能带有相同的本地时间戳。在应用中使用本地时区格式化时间，因为应用掌握正确处理所需的上下文。如果确实需要将整台服务器设为本地时间，请运行 sudo timedatectl set-timezone Europe/Berlin，并使用 timedatectl 验证。

仅支持 IPv4 的服务器会影响德国访客吗？

可以访问，但其中一些访客的访问速度会更慢。多家德国 ISP 为消费者连接提供 DS-Lite 配置，且没有公网 IPv4 地址，因此这些用户必须通过运营商的地址转换网关访问仅支持 IPv4 的服务器，这会增加延迟，并在繁忙时段造成拥塞。发布 AAAA 记录并监听 IPv6，可为这些用户提供直接路径。使用 dig AAAA your-server.example.com +short 和 curl -6 请求进行测试，并确认两种地址族都返回 HTTP 200。