SSD Nodes Learn Hosting plans →
指南 Matt Connor作者: Matt Connor · 更新于 2026-10-21

加拿大VPS托管:数据驻留和延迟怎么判断

PIPEDA并不要求数据留在加拿大。了解魁北克第25号法案、公共部门规则和客户合同的例外,并用实际RTT测量多伦多与纽约数据中心的差异。

您的 VPS 是否需要位于加拿大?

如果法律或合同规定数据必须存储在加拿大境内,那么选择加拿大的 VPS 托管服务是合理的。这是唯一明确的理由。从多伦多家庭网络连接到纽约数据中心的往返延迟约为 18 ms,而到多伦多数据中心约为 3 ms,几乎没有 Web 应用能够分辨其中的差异。

有三点原因会促使人们选择加拿大服务器。数据驻留属于法律义务,因此单凭这一点就能决定服务器位置。延迟可以测量,而且通常比人们预期的更低。使用加元结算对会计人员来说更方便。购买其他服务前,先确认第一点是否适用于您。

本文介绍一般情况下相关规则的运作方式,不构成法律建议。如果隐私法对您的组织具有约束力,应由您的法律顾问给出结论。

数据驻留:唯一的硬性要求

PIPEDA(《个人信息保护与电子文件法》)是加拿大联邦层面的私营部门隐私法,并不要求个人信息留在加拿大境内。该法将向境外处理方发送数据视为处理传输:您的组织仍需对数据负责,处理方必须提供可比的保护,且您必须向相关人员公开说明此类传输。加拿大隐私专员办公室曾在 2019 年就收紧这一要求开展咨询,随后维持了现行立场。Bill C-36 于 2026 年 6 月提交,拟以新的《保护隐私和消费者数据法》取代 PIPEDA 中适用于私营部门的规定;截至 2026 年 10 月,该法案尚未完成二读,因此目前仍适用 PIPEDA。因此,常见的“PIPEDA 要求数据必须存放在加拿大”的说法是错误的,尽管许多主机服务商的宣传材料仍在重复这一说法。

实际的数据驻留规则确实存在,但适用范围更窄。

  • 魁北克第 25 号法案要求,在将个人信息发送到该省以外之前进行评估,并确保信息在接收地获得充分保护。该规定自 2023 年 9 月起生效。它要求完成文档工作并作出能够自证合理的决定,而不是直接禁止传输。
  • 公共部门规则约束公共机构及为其提供服务的公司。新斯科舍省的 PIIDPA 限制将个人信息存储在加拿大境外;2025 年 10 月通过的新版《信息自由和隐私保护法》将于 2027 年 4 月 1 日取代该法。British Columbia 的 FIPPA 曾包含类似规定,直到 2021 年修订后,才允许在完成评估后进行境外存储。
  • 联邦政府相关工作遵循加拿大政府的云计算政策,该政策要求 Protected B 及更高级别的数据留在加拿大。
  • 各省的健康隐私法还会对健康记录的存放地点提出额外要求,而且各省规定不同。
  • 在实际工作中,最常见的驱动因素是客户合同和公共招标。安全问卷中写明“静态数据存储在加拿大”,对您的约束力与法律条文相同,因为这是您签署同意的条款。

实际判断很简单:您能指出具体条款吗?如果组织中没有人能说出要求数据位于加拿大的法律或合同,那么您实际上是在根据延迟和价格作选择。

加拿大数据中心是否不受美国法律管辖?

不能仅凭这一点判断。美国《澄清境外数据合法使用法》(CLOUD Act)适用于由美国服务提供商占有、保管或控制的数据,无论硬件位于何处。因此,由美国公司运营的多伦多区域仍在该法的管辖范围内。如果实际要求涉及外国法律程序,而不是地理位置,那么关键在于谁运营该服务,以及谁持有加密密钥。建筑物位于加拿大,并不能单独回答这个问题。

路由是第二个容易忽视的问题。两个加拿大城市之间的流量经常会经过美国,因为历史上美国的对等互联成本较低。研究人员将这种情况称为回旋路由。在告诉任何人数据包绝不会离开加拿大之前,请先运行 traceroute。

traceroute vps.example.com

跃点名称中可能包含 nyc、chi 或 ash 等城市代码。这些名称只能作为线索,而且可能已经过时。因此,应将其作为向服务提供商询问的依据,而不是证据。对于传输中的数据,可靠的保障是由您控制的加密,而不是地图。如果您希望在自己的机器之间建立专用路径,自托管的 WireGuard VPN 可以提供这样的路径,而不受光纤经过哪个国家的影响。

延迟:应当测量,不要凭推测

光在光纤中的传播速度约为每毫秒 200 km,因此在不考虑任何设备的情况下,距离每增加 100 km,往返时间大约增加 1 ms。多伦多到 Vancouver 的直线距离约为 3,400 km,光缆路径更长,因此理论下限接近 40 ms。实际路径通常更高。

图表Typical round trip from a Toronto connection, milliseconds
此图表背后的数据
[
  {
    "label": "Toronto",
    "rtt_ms": 3
  },
  {
    "label": "Montreal",
    "rtt_ms": 12
  },
  {
    "label": "New York",
    "rtt_ms": 18
  },
  {
    "label": "Chicago",
    "rtt_ms": 24
  },
  {
    "label": "Northern Virginia",
    "rtt_ms": 26
  },
  {
    "label": "Dallas",
    "rtt_ms": 42
  },
  {
    "label": "Vancouver",
    "rtt_ms": 62
  },
  {
    "label": "London",
    "rtt_ms": 88
  },
  {
    "label": "Frankfurt",
    "rtt_ms": 98
  }
]

这些是多伦多连接良好的消费级线路通常公布的数据。它们只能作为起点,不能视为保证值。您的实际数据取决于接入网络和服务商的对等互联,而且会随一天中的时段变化。

有两行数据值得仔细看两遍。多伦多到 Montreal 约为 12 ms,距离足够近,因此在大多数场景下,这两座城市可以视为同一区域。多伦多到 Vancouver 约为 62 ms,反而比多伦多到 Northern Virginia 的 26 ms 更远。数据位于加拿大,并不等于距离用户较近。

不过,最后一公里通常仍是主要因素。家庭光纤会增加几毫秒。线路繁忙时,Cable 的延迟会更高。移动网络本身就会增加几十毫秒。多伦多的手机用户访问多伦多服务器时,可能看到 50 ms 的延迟。将服务器移到 New York,路径会像对所有用户一样增加约 15 ms,总延迟约为 65 ms;而该用户等待的大部分时间仍来自无线链路。

如何测试用户所在地的延迟

首先确定用户实际位于哪里。您的分析数据已经按城市或地区细分了会话。直接查看这些数据,不要根据办公室所在地猜测。

然后从用户所在地进行测量。您无法在渥太华的办公桌前测试温哥华的延迟。可以在目标城市租用一台按小时计费的 VPS,运行 20 分钟后将其销毁。也可以请同事或客户运行一条命令。还可以使用免费的 RIPE Atlas 测量网络:https://atlas.ripe.net。该网络在加拿大多个城市部署了探针,您可以从这些探针发起 ping。

sudo apt update && sudo apt install -y mtr-tiny traceroute iperf3
ping -c 20 vps.example.com

查看最后两行。

20 packets transmitted, 20 received, 0% packet loss, time 19031ms
rtt min/avg/max/mdev = 17.412/18.006/19.882/0.594 ms

avg 是主要延迟数值。mdev 是抖动,表示数据包之间的波动范围。短路径上的任何丢包都值得排查。高抖动对语音和游戏的影响通常大于略高的平均延迟,因为接收端必须根据最慢的数据包而不是典型数据包进行缓冲。

mtr --report --report-cycles 50 vps.example.com

mtr 会显示每一跳的丢包情况。如果因权限错误退出,请使用 sudo 运行。中间跳经常显示并非真实的丢包,因为路由器会将自己生成的 ICMP 响应置于最低优先级。只有一直持续到最后一行的丢包,才是您的流量实际遭受的丢包。先查看最底部一行,再向上排查。

如果 ICMP 被阻止或受到速率限制,请改为测量实际协议的耗时。

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

每个字段都是从请求开始计算的累计秒数。connect 减去 dns 是一次 TCP 往返。tls 减去 connect 是握手过程。ttfb 减去 tls 是一次额外往返,再加上应用响应所需的时间。大多数网站变慢,真正损失的时间就在最后这个间隔中。短路径上的 ttfb 如果为 0.8 s,说明问题出在应用本身,将服务器迁移到其他城市也无法解决。

要测量吞吐量,请将服务器运行在 VPS 上,并从用户所在一侧运行客户端。iperf3 监听 TCP 5201,因此测试前请使用 ufw 开放端口,完成后再将其关闭。

iperf3 -s
iperf3 -c vps.example.com -t 20
iperf3 -c vps.example.com -t 20 -R
iperf3 -c vps.example.com -t 20 -P 8

-R 会反转传输方向,因此可以同时测量下载和上传。-P 8 会打开 8 个并行流。如果 8 个流明显快于 1 个流,限制因素就是长路径上的 TCP 窗口,而不是链路本身,因为单个流每次往返只能传输一个窗口的数据。在温哥华路径上,相同的窗口每秒传输的数据量大约只有纽约路径的三分之一。长距离备份也会受到同样的影响,这就是为什么使用 restic 进行异地备份时,即使线路速度很快,面对远端目标仍然会感觉缓慢。

在 iperf3 运行期间,在第二个终端中持续运行 ping。如果传输过程中往返时间从 20 ms 升至 300 ms,说明您自己的接入设备存在 bufferbloat,迁移到其他数据中心也无法解决。

请多次测量,并在晚上进行测量。用户实际使用的是 9pm 的拥塞情况。4am 的数据则是销售页面更愿意引用的数字。

往返时间对工作负载意味着什么

冷启动页面加载在浏览器能够绘制任何内容之前,需要经历四次往返。

图表Delay before the first pixel on a cold page load, milliseconds
此图表背后的数据
[
  {
    "label": "DNS lookup",
    "toronto_to_new_york_ms": 18,
    "toronto_to_vancouver_ms": 62
  },
  {
    "label": "TCP handshake",
    "toronto_to_new_york_ms": 18,
    "toronto_to_vancouver_ms": 62
  },
  {
    "label": "TLS 1.3 handshake",
    "toronto_to_new_york_ms": 18,
    "toronto_to_vancouver_ms": 62
  },
  {
    "label": "Request and first byte",
    "toronto_to_new_york_ms": 18,
    "toronto_to_vancouver_ms": 62
  },
  {
    "label": "All four round trips",
    "toronto_to_new_york_ms": 72,
    "toronto_to_vancouver_ms": 248
  }
]

DNS 查询会发送到解析器,而不是您的服务器,并且通常会被缓存,因此热访问会跳过这一步。按端到端延迟计算,冷启动加载通过 New York 路径时会先增加 72 ms,通过 Vancouver 路径时会先增加 248 ms。与一次 400 ms 的数据库查询相比,New York 的延迟较小;Vancouver 的延迟则不同:它超过该查询延迟的一半,冷启动用户确实需要承担这部分时间。连接建立后,HTTP/2 和 HTTP/3 可以同时在同一连接上承载多个请求,因此这项成本只支付一次,而不是每个文件支付一次。将静态资源放到 CDN(内容分发网络)后,这些资源基本不再受源站所在城市影响。这就是为什么欧洲用户访问 Toronto 的延迟为 98 ms 时,仍然可以快速加载页面。

实时多人游戏属于相反的场景,因为往返延迟本身就是体验的一部分。在快速动作游戏中,低于约 50 ms 通常会感觉即时;达到约 80 ms 时,玩家开始察觉延迟;超过 120 ms 后,玩家会将问题归咎于服务器。在这种场景中,区域选择确实会决定产品体验。节奏较慢的服务器宽容得多,因此在 VPS 上运行 Minecraft 服务器可以承受一些会毁掉射击游戏体验的距离。

区域选择对数据库的影响最严重。不要将应用放在一个区域,而将数据库放在另一个区域。每次查询都是一次往返。一个页面如果发出 40 次查询,就要承担 40 次往返:每次 18 ms 时,总延迟接近 1 秒;每次 62 ms 时,总延迟超过 2 秒。即使该页面在数据库与应用位于同一台服务器时的性能分析结果只有 30 ms,也会出现这种情况。将数据异步复制到其他区域适合只读副本和灾难恢复。跨越长距离执行同步提交,则会将这段路径的延迟加入每一次写入。

交互式会话介于两者之间。SSH 在约 100 ms 的延迟下仍然较舒适,超过该值后会感觉卡顿,因为每次击键都要等待回显返回。mosh 会在本地进行预测,从而隐藏大部分延迟。Webhook 和内部 API 应始终与其调用的服务位于同一区域。

账单、货币和税费

使用加元付款可以避免发卡机构收取的外币交易费。截至 2026 年 8 月,该费用通常约为 2.5%;同时,账簿也可统一使用一种货币。加拿大服务商会在发票中计入 GST 或 HST,已注册企业可以将其作为进项税抵扣。这是财务问题,应由财务规则决定,不应影响网络流量的转发位置。如需了解服务器的实际成本,以及如何比较套餐并避免受续费价格影响,请阅读VPS每月实际成本。

小型市场的代价

与美国相比,加拿大的托管市场较小,因此客观建议也应说明需要放弃什么。

  • 争夺您预算的服务商更少,因此对于同等配置的机器,每 GB RAM 或磁盘的价格通常更高。
  • 容量主要集中在多伦多和蒙特利尔,温哥华和卡尔加里的容量较少。用于故障转移的第二个加拿大区域通常距离较远,或者最终仍需离开加拿大。
  • 小型区域服务商可能只运营一栋机房,并依赖一两家上游运营商。请询问上游运营商的数量,并确认其中一家发生故障时会如何处理。
  • 硬件选择更少。在美国区域更容易找到大规格实例和 GPU 机器,因此您希望的城市中,可能没有所需规格的 GPU VPS。
  • 小型服务商的支持覆盖范围需要认真确认,不能只看营销宣传。请询问人工支持人员何时在线。

蒙特利尔的价格是例外。魁北克的水力发电成本较低,冬季也能降低制冷成本,因此蒙特利尔地区拥有大量容量,价格可以与美国区域竞争。如果您的要求是位于加拿大,而不是指定某个城市,应优先考虑这里。

如果加拿大的 VPS 层级对您的工作负载来说过小,请先比较VPS 与专用服务器,再决定问题是否确实在于国家选择。

何时应选择加拿大的 VPS 托管

  1. 如果法规、合同或公共部门政策明确指定加拿大,就应在加拿大托管。本文中的其他内容均不适用;您还应要求服务提供商以书面形式确认数据驻留承诺。
  2. 如果用户集中在加拿大某个都会区,且工作负载受延迟限制,例如多人游戏、语音通信、远程桌面或交易,就应选择距离最近的城市进行托管,并在签约前测量两种方案的性能。
  3. 如果用户分布在全国各地,多伦多或蒙特利尔可以覆盖最大比例的人口。在静态资源前面部署 CDN,对温哥华用户的改善通常大于迁移源站。
  4. 其他情况占绝大多数。根据价格和实际获得的硬件做选择,然后确认凌晨 2 点需要支持时服务商能提供什么帮助。先对候选方案进行基准测试,因为规格表相同的两个方案,性能不一定相同:如何正确测试 VPS 性能。

无论选择哪种方案,都应将决策理由记录下来。下一个询问是否应将服务部署在加拿大的人,值得获得比猜测更可靠的答案。如果当时的依据是合同条款,还需要有人再次找到该条款。服务器创建后,新 VPS 上线后的前十分钟 对安全性的影响远大于所在城市。

FAQ

PIPEDA 是否要求我的数据必须留在加拿大?

不要求。PIPEDA(《个人信息保护与电子文件法》)没有针对私营部门的数据驻留规定。将个人信息发送给其他国家的处理者属于跨境处理:您的组织仍需对数据负责,处理者必须提供同等程度的保护,且您必须向相关人员明确说明这一点。加拿大隐私专员办公室曾在 2019 年就改变这一立场进行咨询,之后维持了原立场。数据驻留要求来自其他规定,例如魁北克第 25 号法案的评估要求、新斯科舍省的 PIIDPA 等公共部门法律、加拿大政府的云计算指引,或您自己的客户合同中的条款。

加拿大用户会注意到服务器位于美国吗?

对于普通 Web 应用,不会。从多伦多到纽约的往返时间约为 18 ms,到北弗吉尼亚约为 26 ms;这两者都低于多伦多到温哥华的 62 ms。用户很早就会注意到服务器响应时间和页面大小,通常不会注意到 20 ms 的网络延迟。但在实时游戏、语音通话,以及需要两个人相互即时响应的场景中,用户确实会注意到延迟。

加拿大境内的数据中心是否不受美国法律管辖?

不一定。美国 CLOUD Act 适用于美国服务提供商占有、保管或控制的数据,无论服务器位于何处。因此,美国公司运营的加拿大区域仍受该法覆盖。如果您实际担心的是外国法律程序,应关注服务的运营方以及加密密钥的持有者,而不是建筑物的地址。使用由您自行持有的密钥进行加密,会改变服务提供商能够交出的数据范围。

如何测量我不居住城市的网络延迟?

在该城市租用按小时计费的 VPS,运行 ping -c 20 和 mtr --report --report-cycles 50 测试到您自己服务器的延迟,然后销毁该 VPS。RIPE Atlas 网络是另一种免费选择,其探针分布在加拿大各城市。如果 ICMP 被阻止,可以改用 curl -o /dev/null -s -w '%{time_connect} %{time_starttransfer}\n' https://your.server/ 测量实际请求。它会提供 TCP 往返时间以及从请求开始到收到第一个字节的完整耗时。

这篇文章对您有帮助吗?