阿姆斯特丹 VPS 怎么选：延迟、互联与数据驻留

选择阿姆斯特丹的 VPS 托管

选择阿姆斯特丹的 VPS 托管，首先是网络层面的决策。阿姆斯特丹是欧洲主要的网络互联节点之一，大量独立网络在此汇聚并直接交换流量。位于该都会区的服务器通常可以通过较短的路径连接英国、北欧、德国、法国和比荷卢地区，中间经过的网络较少。

这就是主要理由。本指南其余内容将帮助您确认这一理由是否适用于您的用户，因为它并不适用于所有用户。如果您的客户群分布在西北欧，阿姆斯特丹通常是一个不错的默认选择。如果大多数流量来自华沙、伊斯坦布尔、圣保罗或多伦多，阿姆斯特丹则不是理想选择，因为荷兰良好的网络互联并不能缩短到这些地区的距离。

互联网交换中心的实际含义

互联网交换中心（IXP）是一个共享交换网络。各个独立网络在其中租用端口，接入一次后，就可以与其他成员直接交换流量。阿姆斯特丹最知名的交换中心是 AMS-IX，即阿姆斯特丹互联网交换中心。该市不只有一个交换中心，交换中心的数量也不是你需要关注的重点。

要理解交换中心为什么会改变延迟，需要先了解数据包跨越网络的两种方式。第一种是转接（transit）：你向大型网络付费，由它将你的流量传送到互联网的其他部分。第二种是对等互联（peering）：两个网络同意直接相互传递流量，通常双方都不需要支付费用。这里的每个网络都是一个自治系统（AS），即拥有自己的编号和路由策略的网络。

转接路径的选择不仅取决于地理位置，也取决于商业关系。来自某个欧洲城市服务器、发往另一个城市宽带用户的数据包，完全可能先到第三个城市，在那里切换网络后再返回。网络没有故障。该路径只是由费用关系和路由策略共同决定的。在交换中心，两个网络可以在本地直接交接数据包，因此路径更短，经过的网络更少，也减少了出现拥塞的位置。

下面是经常被忽略的一点。城市中存在交换中心，并不意味着你的 VPS 已经接入该交换中心。真正重要的是服务商自己的网络：它购买了哪些转接服务，加入了哪些交换中心，是否与用户所使用的消费者网络和移动网络建立对等互联，以及与这些网络之间拥有多少容量。同一栋楼中的两台服务器，其对外路径也可能完全不同。向服务商索要其 AS 编号，然后在 PeeringDB 中查询该编号。网络会在其中公布自己所在的机房和交换中心。你也可以直接从实时路径中读取 AS 编号，下面的测量部分会说明具体方法。

阿姆斯特丹还是法兰克福：根据用户所在地决定，而不是看地图

这是大多数读者实际面临的选择，而且这两座城市都是重要的互联节点。法兰克福设有 DE-CIX，通常适合中欧、东欧和东南欧，也适合通往维也纳、华沙、布拉格和中东的网络路径。阿姆斯特丹则更适合英国、爱尔兰、斯堪的纳维亚和比荷卢地区，也适合使用在西北欧登陆的海底电缆的网络流量。应将这些视为趋势，而不是测量结果。路由会变化，提供商会更换上游，而且您的提供商建立的对等互联关系比任何城市级概括都更具体。

因此，请使用您自己的数据来决定。

1. 记录用户的实际所在地。Web 服务器访问日志、分析数据或客户名单中通常已经包含这些信息。
2. 根据收入或活跃账户等有实际意义的指标为这份列表加权，而不要直接使用会被机器人流量夸大的原始访问次数。
3. 在每个候选城市租用最小规格的方案，持续一个月，并从真实用户连接分别测量到这两座城市的指标。
4. 比较您收集的数据，不要比较营销页面上的数字。

在您为此投入一周时间之前，先说明一个客观限制。对于位于西欧的用户群体，两个互联良好的欧洲大都市之间的差异，通常小于应用本身增加的延迟。一个页面如果连续执行 10 次数据库查询，就要承受 10 次往返延迟，因此查询模式带来的成本可能高于城市选择。也请测量应用本身。法兰克福 VPS 选择指南从另一个角度讨论了相同问题，而最终决定因素往往很普通，例如某个位置是否提供您需要的方案规格和磁盘容量。

如何自行测量到阿姆斯特丹的延迟

请从用户实际使用的连接运行这些命令，或尽量从接近该连接的位置运行。曼彻斯特的移动网络连接不能用办公室光纤代替。

在 Debian 或 Ubuntu 上，先安装这些工具。

sudo apt update && sudo apt install -y mtr-tiny traceroute curl

先测量往返次数。

ping -c 20 ams.example.com

末尾的摘要标记为 rtt min/avg/max/mdev。avg 是典型往返时间，单位为毫秒；mdev 表示往返时间的波动程度，也就是抖动。在同一段摘要中读取丢包百分比。目的地主机发生丢包是真正的问题。某个中间跃点报告丢包，但其后的每个跃点数据都正常，通常不构成问题，因为路由器会降低对发往自身数据包的回复优先级。

然后查看路径本身。

mtr --report --report-wide --show-ips --aslookup --report-cycles 100 ams.example.com

每一行代表一个跃点，--aslookup 会输出 AS 编号，因此您可以看到数据包经过了哪些网络，以及在哪个位置离开您的服务提供商网络。查找往返时间开始升高，并在后续每个跃点持续偏高的位置：延迟就是在那里增加的。如果 mtr 因无法打开原始套接字而退出，请使用 sudo 运行。某些网络会降低 ICMP 的优先级或丢弃 ICMP，因此还应按照用户的实际连接方式进行测量，即通过 TCP 连接到您提供服务的端口。

sudo mtr --tcp --port 443 --report --report-cycles 100 ams.example.com

然后区分网络和服务器造成的延迟。

curl -o /dev/null -s -w 'dns %{time_namelookup}\nconnect %{time_connect}\ntls %{time_appconnect}\nttfb %{time_starttransfer}\ntotal %{time_total}\n' https://ams.example.com/

每个值都是从请求开始计时后的秒数，因此应读取这些值之间的间隔。connect 减去 dns 大致是一次往返时间，即 TCP 握手耗时。tls 减去 connect 是 TLS（传输层安全）握手耗时。TLS 握手需要更多次往返，因此距离越远，增长速度通常越快。ttfb 减去 tls 主要是服务器处理请求所需的时间。正因为可以这样拆分，curl 比 ping 更适合用于购买决策。总耗时较高但 ttfb 间隔较小，说明服务器距离较远。ttfb 间隔较大但连接速度快，说明服务器距离较近，而应用响应较慢。

延迟也会随时间变化，因为网络拥塞程度会变化。应在一天内分时段采样，不要只相信一次测试结果。

while true; do date -Is; ping -c 10 -q ams.example.com | tail -2; sleep 300; done | tee latency.log

网络只是购买决策的一半。磁盘和 CPU 是另一半。在超额订阅的节点上，即使服务器位置合适，使用体验仍然可能很慢，因此在承诺购买一年之前，请先使用 正规的 VPS 基准测试 测试试用方案。

用通俗语言说明欧盟数据驻留

数据驻留是指数据存储和处理的物理位置。荷兰属于欧盟和欧洲经济区，因此，位于阿姆斯特丹的服务器会将您的数据保存在欧盟基础设施上。这解决了位置问题，但位置只是合规问题中的一个因素。

《通用数据保护条例》（GDPR）并不禁止个人数据离开欧盟。它规定了数据传输的条件，也适用于代表您处理数据的其他公司。因此，真正有用的问题不是“服务器是否位于欧盟”，而是“这份数据的每个副本最终会到哪里”。

数据驻留声明通常会在这里失效。VPS 位于阿姆斯特丹，数据库也在该服务器上。随后，备份被发送到其他区域的对象存储，应用日志被传输到托管搜索服务，错误追踪数据被发送到监控供应商，事务性邮件通过第三方发送，用户文本则被提交到 API 进行摘要。每一步都会将个人数据传输到某个位置。位置要求涵盖所有这些环节，而不只是您有意选择的那台机器。

请区分这两个目的，因为它们会导致不同的设计。如果合同、监管机构或客户要求使用欧盟基础设施，这是合规要求。该要求应明确写入文件，并且可能要求您始终留在一个区域内。如果您希望服务器靠近用户以加快页面加载速度，这是延迟要求，可能需要增加区域。使用合规术语来解释性能决策，会导致您之后无法回答这两个问题中的任何一个。

请向供应商确认谁可以访问该机器、支持人员位于哪里、该公司受哪些法律管辖，以及是否有任何子处理者位于欧洲经济区之外。请将答复写入数据处理协议，因为审计人员需要查看签署的文件，支持工单不能替代该文件。完整方法请参阅针对加拿大数据编写的数据驻留框架，该方法同样适用：列出数据，列出接触这些数据的每个处理者，记录必须满足的规则，最后再选择位置。这些内容用于说明应提出的问题，不构成法律建议。

选择阿姆斯特丹无法解决的问题

• 与其他地区之间的距离。信号在真空光纤中的传播速度约为光速的三分之二，而且电缆路径始终比直线更长。因此，无论选择哪个欧洲城市，新加坡用户都必须承担这段距离带来的延迟。
• 请求频繁交互的应用。每个等待前一个请求完成的请求，都要再次承担一次往返延迟。
• 单区域风险。一座城市中的一台 VPS 属于单一故障域。即使对等互联良好，误删错误的数据卷仍然无法避免。
• 资源超售的硬件。互联良好城市中的繁忙节点，仍然是繁忙节点。

如果用户分布在多个大洲怎么办

规则很简单：将服务器放在距离用户最近的网络接入点。如果用户分布在多个大洲，将服务器放在中间位置会让两组用户的体验都变慢，因为两组用户都不在服务器附近。

实际有两种解决方案。将所有可缓存内容放在 CDN（内容分发网络）后面。这样源站仍位于 Amsterdam，而图片、样式表、脚本和缓存页面由各用户附近的节点提供。或者在另一个区域运行第二台服务器，并有计划地解决数据同步问题，例如使用只读副本，或使用已测量并记录延迟的复制方案。这两种方案的成本都高于只运行一台服务器。这就是用户分布分散所需承担的实际成本。

如果流量中有很大一部分来自北美，位于 Toronto 的 VPS 为这些用户提供的服务会优于任何欧洲城市。对于南美用户，托管在 Brazil 的 VPS 可避免每次请求都经过一次跨大西洋往返。用户位于欧洲，且主要位于欧洲北部和西部时，选择 Amsterdam 是合理的。这是一个明确的判断，而上面的命令可用于根据您自己的流量进行验证。

FAQ

阿姆斯特丹的 VPS 是否比法兰克福的更快？

对您的用户而言，可能更快。这两个城市都是重要的网络互联节点，因此差异取决于用户所在位置，以及各提供商与哪些网络建立了对等互联，而不是城市名称。阿姆斯特丹通常更适合英国、爱尔兰、斯堪的纳维亚和比荷卢地区；法兰克福通常更适合中欧和东欧。先分别租用两地最小的月付方案，然后从真实用户的连接运行 mtr --report --aslookup 和一次 curl -w 测试，持续一周后再决定。

在阿姆斯特丹托管是否意味着我的服务符合 GDPR？

不符合。这样只能说明数据位于欧盟基础设施上，回答了其中一个问题。合规性还涉及您的法律依据、数据处理者、备份、日志，以及您向其发送个人数据的所有第三方服务。位于阿姆斯特丹的服务器如果将错误跟踪数据发送给 EEA 以外的供应商，仍然会把这些数据传出 EEA。位置是最容易处理的部分，也是人们往往只做到这里的部分。

什么是 AMS-IX？它会影响我的 VPS 吗？

AMS-IX 是阿姆斯特丹互联网交换中心，是一个共享交换网络。独立网络可以在此直接互联并互相传输流量，而不必支付传输提供商的费用来承载它们之间的流量。您的 VPS 只有在提供商接入 AMS-IX 后，才会通过它受益。城市中存在互联网交换中心，只有在您的提供商接入该交换中心，并与用户所使用的网络建立对等互联时，才会对您有帮助。请索取提供商的 AS 号，然后在 PeeringDB 上检查该 AS 号与哪些网络建立了对等互联。

在按年付费前，如何测试 VPS 的网络？

先购买最小的月付方案。运行 ping -c 20 测试往返时间和丢包率，然后运行 mtr --report --report-wide --aslookup --report-cycles 100 查看路径经过哪些网络，接着针对真实 HTTPS 页面运行 curl -w，以区分网络距离和服务器速度。在不同时间重复测试，因为网络拥塞会随一天中的时间变化。测试时应使用用户实际使用的连接，而不只是办公室的连接。保留日志，以便比较记录的数值，而不是凭印象判断。