蒙特利尔和三个美国城市报价单逐字相同：这时候选节点其实是在选辖区

报价单一模一样就随便挑一个，这个判断漏掉了最关键的一层

把加拿大蒙特利尔的云主机页面，和美国波特兰、美国南卡罗莱纳、美国拉斯维加斯三张页面并排打开，你会撞见一件反直觉的事：四张页面上的档位、配置字段、价格数字，逐字相同。这时候最省事的反应是——既然一模一样，那就随便挑一个，或者按"哪个离我的用户近"来定。

这个反应很自然，但它漏掉了一层。页面相同只说明一件事：这几个城市卖的是同一套产品模板。模板相同，不代表城市相同。当价格、配置、端口、流量都不再提供任何区分度的时候，页面上没有被写出来的那一项，反而成了唯一真正有区分度的变量——这台机器物理上落在哪个国家，决定了它归哪套法律管。

举个例子说明为什么这件事不是玄学。一家面向北美客户的 SaaS，客户在采购问卷里问了一句"我们的数据存在哪个国家"。如果你答"美国某地"，对方可能接着问"那我们的加拿大员工数据呢"；如果你答"加拿大"，对方可能追问"是否会被美国方面的法律程序调取"。这两个追问，靠看报价单是回答不了的，因为它们根本不是价格问题，也不是配置问题。

本文只讨论一个问题：当报价与配置都退场之后，还剩下什么能决定你选哪个城市。答案是辖区，而辖区是可以被拆成一份可检查清单的。

先把事实摆平：四张页面逐字相同，到底意味着什么

事实先讲清楚，避免后面的推论建立在模糊印象上。加拿大蒙特利尔云页面（https://www.idc10000.net/mengtelieryun）给出两条线。线一为 1G 端口：A 档 1核1G / 30G / 1G 端口 1.5T 流量，99 元/月；B 档 2核2G / 40G / 1G 端口 2T 流量，199 元/月；C 档 2核4G / 20G / 1G 端口 2T 流量，299 元/月；D 档 4核8G / 20G / 1G 端口 2T 流量，399 元/月。线二为 100M 端口：2A 档 1核1G / 30G / 100M 端口 500G 流量，299 元/月；2B 档 2核2G / 40G / 100M 端口 3T 流量，599 元/月；2C 档 4核4G / 60G / 100M 端口 4T 流量，799 元/月；2D 档 4核8G / 100G / 100M 端口 5T 流量，1299 元/月。以上均以官网实时价为准。

美国波特兰云（https://www.idc10000.net/botelanyun）、美国南卡罗莱纳云（https://www.idc10000.net/nankaluolainayun）、美国拉斯维加斯云（https://www.idc10000.net/lasiweijiasiyun）三张页面，与蒙特利尔页的两条线逐字相同——同样的档位名、同样的字段、同样的数字。

这说明什么？说明这几张页面是同一套产品模板铺在不同城市上，页面字段本身不承载任何地区信息。你在页面上看到的每一个字，都无法告诉你蒙特利尔和拉斯维加斯有什么不一样。它不会告诉你当地的电力成本、不会告诉你看海缆走向、更不会告诉你数据落在魁北克和落在内华达分别适用哪套规则。

作为对照，美国洛杉矶云页面（https://www.idc10000.net/luoshanjiyun）是另一套模板：A 档 1核2G / 40G、B 档 2核4G / 80G、C 档 4核8G / 160G、D 档 6核16G / 320G，四档均为 100M 端口，价格分别为 150、280、550、1000 元/月（洛杉矶页数据，以官网实时价为准）。洛杉矶页与前述四页并不相同，这恰恰反证了一点：页面数字的差异来自产品模板的差异，而不是来自城市本身的差异。所以拿页面数字去反推"哪个城市更好"，从方法上就走错了路。

价格和配置都不再区分时，剩下的变量是：地理位置 → 国家 → 法律辖区

把变量一个个划掉。配置？四页相同。价格？四页相同。端口与流量？四页相同。剩下的东西只有一样，它从来没出现在页面字段里：这台服务器所在的机房，坐标落在哪条国界线之内。

地理坐标本身不重要，重要的是坐标之上叠着两套东西：一套是物理的（电网、气候、骨干路径、海缆登陆点），一套是制度的（哪个国家的法律能管到这台机器、哪个国家的执法机关能敲门、哪套隐私规则约束你对数据的处理）。前者影响的是可用性，后者影响的是你能不能签下这份合同。

制度这一层就是"辖区"。它的运作方式很朴素：一台服务器摆在某个国家境内，通常就会被认为处于该国的管辖范围。于是问题从"这台机器快不快"变成"这台机器受谁管、谁能调它的数据、我要不要把数据放进来"。

这里要区分两个容易混在一起的概念。数据主权说的是数据受哪国法律支配；数据驻留说的是数据物理上存放在哪里。驻留是手段，主权是结果。你把数据放在加拿大，是为了让它受加拿大那套规则支配——如果放过去之后，另一国的法律依然能直接调走它，那么"驻留"就只完成了一半。

顺着这条线往下看，四个城市的差别立刻显现出来：蒙特利尔在加拿大魁北克省，另外三个都在美国，分属俄勒冈州、南卡罗莱纳州、内华达州。它们同属北美，但分属两个不同的法律体系。四张报价单一样，这四个辖区可一点都不一样。

辖区差异具体落在四件事上：出境、调取、合同、语言

以下仅为技术部署视角的通用介绍，不构成法律意见，具体合规判断请咨询专业法务或合规顾问。下面写的都是广泛公开可知的常识性事实，不引用具体条款编号、罚则金额和生效日期细节，凡涉及分阶段推进的内容，一律以官方文本为准。

第一件：数据出境与跨境传输的告知

加拿大联邦层面有个人信息保护法律（通常称 PIPEDA），魁北克省另有本省的隐私立法，即第 25 号法案（Law 25），对个人信息处理、跨境传输的告知、隐私负责人任命等方面提出要求。这些要求的关键在于"告知"二字：当个人信息被传到省外或境外之前，往往需要评估接收地的保护水平，并向个人作出相应说明。

落到技术上，这意味着一件很具体的事：如果你把魁北克客户的数据搬到了美国节点，你不一定是被禁止这么做，但你可能需要先做一次出境评估，并在隐私政策或告知文件里写清楚。而如果你把数据留在蒙特利尔，这一步的复杂度会低很多——不是消失，是降低。

反过来看美国一侧。美国三个城市之间，辖区差异同样存在：俄勒冈州有本州的消费者隐私立法，内华达州也有本州的隐私相关立法，南卡罗莱纳州则未见广为人知的综合性消费者隐私立法，实践中多按联邦与行业性规则处理。州法不同，意味着同为"美国节点"，落在俄勒冈和落在南卡罗莱纳，你所处的州级合规环境并不完全一样。

第二件：政府调取与域外效力

这是"数据驻留不等于数据主权"最直接的体现。美国有 CLOUD Act 一类的法律框架，其核心特征是域外效力——在满足特定条件时，美国方面可以要求受其管辖的服务商提供其掌控的数据，即便这些数据物理上存放在境外。这一点对"把数据放加拿大就能完全避开美国法律程序"的想法，是一个需要正视的现实约束。

对技术人员的实际含义是：服务商的注册地与控制权，和数据存放地一样重要。你在评估一个节点时，既要问机器在哪，也要问运营主体受哪些法域约束。这两个问题不能互相替代。

第三件：合同承诺能不能兑现

很多 B 端合同里会写"数据不得出境""数据须存储于加拿大境内""未经书面同意不得向第三方披露"。这类条款写起来容易，难的是兑现。合同承诺是法律义务，但它必须由技术架构来落地：数据到底落在哪台机器上、备份在哪、日志在哪、CDN 缓存会不会顺手把一份副本留在别的国家、运维人员从哪个国家远程登录。

一旦你在蒙特利尔部署了主库，却把自动备份同步到了美国节点，那么"数据不出境"这句话在技术上就已经不成立了。辖区选择不是下单那一刻的动作，而是贯穿整个架构的动作。

第四件：本地语言与服务要求

魁北克还有一个其他三个城市都没有的变量：法语。当地对法语在服务、商业沟通、面向消费者的文件方面的要求是公开广泛讨论的话题。做本地业务时，界面文案、客户支持、合同条款、隐私告知文件的语言版本，都会被本地客户看在眼里。

这一项严格说不属于隐私法，但它同样是"辖区"这个词的一部分：辖区不只是法律条文，还包括当地市场对服务的预期。对魁北克本地客户来说，"我们的数据有没有离开魁北克"这个问题的敏感度，通常高于美国客户对同类问题的敏感度。这不是技术差异，是市场差异，但它真实地影响你的成交率。

客户问"我们的数据存在哪个国家"，你该怎么答：一份可执行的自查顺序

先说会问这个问题的都是谁。最常见的是四类：面向北美用户的 SaaS，采购方的安全问卷里必定有数据存放地一项；魁北克省本地业务，客户对数据出境的敏感度天然偏高，还会叠加法语服务的预期；加拿大本地企业上云，合同里往往已经白纸黑字写了数据不得出境；美国企业在加拿大设的分支机构，需要本地落地节点，同时又要满足集团总部的统一合规口径。

被问到时，最糟的回答是"应该在某某地方吧"。下面是一个可以直接照着走的检查顺序，每一步都能产出一个可写进问卷的事实：

• 第一步，确认数据落在哪个国家与哪一级行政区。不要只看服务商宣传的城市名，要确认机房的实际归属。蒙特利尔属于加拿大魁北克省，波特兰属于美国俄勒冈州，拉斯维加斯属于美国内华达州，南卡罗莱纳即美国南卡罗莱纳州。
• 第二步，把数据分类，而不是把机器分类。按是否含个人信息、是否含敏感个人信息、是否含客户商业机密、是否只是公开内容，把数据拆成两到三类。辖区约束只对其中一部分生效。
• 第三步，找出所有副本。主库、从库、每日备份、跨区灾备、对象存储的冗余副本、日志采集、监控数据、CDN 边缘缓存。绝大多数"数据其实出境了"的事故，都出在副本上，而不是主库上。
• 第四步，核对合同原文与你的实际架构。合同写"存储于加拿大境内"，你就要确认第三步列出的每一份副本都在加拿大境内。合同写"不得出境"，就要确认连备份也没有跨到美国节点。
• 第五步，把结论写成一句可交付的话。例如"客户个人数据存储于加拿大魁北克省节点，备份同区保存，不含个人信息的静态资源经分发网络全球缓存"。这句话能直接进采购问卷，也能直接进隐私告知文件。
• 第六步，留痕。把架构图、节点清单、数据流说明存档。下一次客户再来问，或者监管来问，你拿得出东西。

走完这六步，你会发现"数据存在哪"这个问题本身不难，难的是大部分团队从来没把副本清单列全过。辖区选择的踩坑，九成发生在没列全的那部分。

架构上怎么处理：把数据分层，而不是把机器分层

辖区约束的正确解法，不是"把所有东西都塞进加拿大"，也不是"全部放美国图省事"，而是按数据敏感度分层，让每一层去它该去的地方。

一个典型的分层思路（以下为典型部署思路，并非特指某一真实客户）：

• 强约束层：个人信息、客户业务数据、账号凭据、支付相关信息。这一层必须与合同承诺的辖区严格一致，主副本都在同一辖区内，备份也不跨区。
• 中约束层：业务日志、行为埋点、运维监控数据。这一层常被忽略，但它往往包含 IP、账号标识这类可识别信息。建议与强约束层同区存放，或先做脱敏再允许跨区。
• 弱约束层：静态资源、公开文档、安装包、媒体文件、纯计算型中间结果。这一层可以自由跨区，也可以交给分发网络，它对辖区基本不敏感。

接下来是那个高频问题：应用和数据库要不要同区。答案是——应用与数据同区是最省事、也最容易解释的方案，因为你可以对外说"整套系统都在加拿大"。但同区不等于同机，把应用层放在美国、数据库留在加拿大在工程上是可行的，代价是每一次跨区访问都要走一趟跨境链路，延迟与稳定性都要重新评估，同时你还得向客户解释"应用在美国"这件事对数据主权意味着什么。

更麻烦的是反向组合：应用在加拿大、数据库在美国。这种组合几乎必然会让"数据不出境"的承诺失效，因为数据是跟着库走的，不是跟着应用走的。判断标准很简单：数据在哪台机器上持久化，辖区就由那台机器决定。

在节点组合这件事上，一万网络深耕 IDC 19 年（成立于 2007 年），总部位于深圳南山，除海外节点外，在华南、华东、华北以及中国香港均有节点，支持跨区组合部署；自营机柜最快 1 分钟上架，7×24 中文工单平均 5 分钟响应。这类多节点布局的价值在辖区场景下很直接：你可以把强约束层放在承诺的辖区内，把弱约束层放到离用户更近的地方，而不必为了辖区把整套架构都绑死在一个城市。

先选错了怎么办：迁区的成本主要花在哪

很多人不敢在辖区上做决策，是因为觉得"选错了改起来很贵"。把成本拆开看，会发现贵的不是搬家本身，而是搬家前后的几件隐形成本。

第一块成本是数据搬迁与校验。全量导出、跨区传输、导入、比对一致性，数据量越大耗时越长。对数据库而言，真正麻烦的是搬迁期间的增量：你需要一段双写或追日志的窗口，否则切过去的数据是不完整的。

第二块成本是停机窗口与切换演练。辖区迁移往往意味着换 IP、换域名解析、重新签发证书、更新防火墙白名单，还要通知所有对接方。真正耗时的是演练，不是切换本身。

第三块成本是配置与依赖重建。监控、告警、备份策略、日志采集、密钥管理、对象存储的桶策略，这些在源区跑得好好的东西，到目标区都要重来一遍。它们不显眼，但加起来常常比搬家本身还费时间。

第四块成本，也是最容易被忽略的一块：合规回补。如果数据曾经在不被允许的辖区存放过，迁走不等于问题解决，你可能需要向客户或监管作出说明，并补上告知与记录。这一块的成本不在工程侧，但它真实存在，且往往比工程侧更麻烦。

所以退路的关键不是"能不能迁"，而是一开始就把迁区这件事设计成可能的：数据与配置分离、基础设施用可复现的模板描述、节点清单集中管理、域名解析不要写死 IP。做到这几点，迁区就从"重构"降级为"重新部署"。反过来，如果你把所有东西手工堆在一台机器上，那迁一次就真的是伤筋动骨。

辖区问题答疑：七个被反复问到的场景

客户问"我们的数据存在哪个国家"，怎么答才不出错？

答事实，不答推测。先确认机房所属的国家与一级行政区，再确认所有副本的位置——备份、日志、对象存储、CDN 缓存都要算进去，很多人只答了主库，结果事后被发现备份在另一个国家，承诺就不成立了。给客户的答案应该是一句完整的话，包含三要素：数据存放在哪个国家、备份是否在同区、不含个人信息的内容如何处理。拿不准的部分直接说"我核实后书面回复"，比当场给一个模糊答案安全得多。把这句话连同架构图一起存档，下一次客户或监管再问，你就能直接调出来。

魁北克第 25 号法案（Law 25）对技术部署意味着什么？

从技术视角看，它把两件事变成了工程任务。一是跨境传输的告知：个人信息在传出之前往往需要先评估接收地的保护水平，并把这件事对个人说清楚，这要求你有一份能随时导出的数据流清单，说得出数据从哪来到哪去。二是隐私负责人的任命：组织内部需要有人对个人信息处理负责，这要求技术上能提供访问审计、留存期限、删除执行这些能力。具体条款与分阶段实施细节以官方文本为准，此处不作展开。落地建议很简单：先把数据流图画出来，再对照看哪些环节需要补告知。

加拿大节点能不能同时服务美国用户？会不会两头都不合规？

能服务，而且这是很常见的架构。用加拿大节点服务美国用户本身不产生合规问题，问题出在你对外怎么承诺。如果你对美国客户说数据存在美国，那在加拿大节点上就是不实陈述；如果你对加拿大客户说数据不出境，那么美国节点上的任何一份副本都会推翻这句话。解法是分开承诺、分开存放：加拿大客户的数据放加拿大节点，美国客户的数据放美国节点，两边各自兑现各自的说法。真正危险的从来不是"一个节点服务两个国家"，而是"一套数据同时背了两份互相矛盾的承诺"。

应用放美国、数据库放加拿大，这种拆法行不行？

工程上可行，但要想清楚两件事。一是性能：应用层每一次读写都要跨一次境，往返延迟会直接叠加到每一次请求上，对高频读写的业务影响明显，通常要靠缓存和连接池来缓解。二是解释成本：你要能向客户说清楚，为什么应用在美国而数据在加拿大，以及这种拆分是否影响数据主权的承诺。判断标准只看一条——数据在哪台机器上持久化，辖区就由那台机器决定。所以这种拆法从主权角度看是成立的，代价是延迟和解释。反向拆法（应用在加拿大、库在美国）则基本不成立，因为那样数据实质已经出境了。

合同写了"数据不出境"，技术上怎么验证自己做到了？

靠三样东西，缺一不可。第一是资产清单：把所有存放数据的位置列出来，包括主库、从库、备份、日志、对象存储、CDN 缓存、第三方 SaaS 集成，这份清单必须写到具体机房所在国家。第二是数据流图：画出数据从哪里产生、经过哪些系统、最终落在哪，特别注意那些被自动同步出去的部分。第三是定期核对：架构会变，新人会加新服务，清单需要定期复查而不是一次做完就归档。最容易出问题的环节是第三方集成——你把数据存在加拿大，却接入了一个把日志传到境外的分析服务，合同承诺照样失效。

辖区选错了能不能迁？迁一次的主要成本在哪？

能迁，成本可以分成四块。数据搬迁与一致性校验是第一块，数据量越大越慢，难的是搬迁期间的增量同步。停机窗口与切换演练是第二块，换 IP、改解析、重签证书、更新白名单、通知对接方，真正耗时的是演练。配置与依赖重建是第三块，监控、告警、备份策略、日志采集、密钥管理都要在目标区重做。第四块是合规回补，如果数据曾在不允许的辖区存放过，迁走不等于解决，还可能需要补告知与记录。降低迁区成本的办法是提前设计：数据与配置分离、基础设施模板化、域名解析不写死 IP，做到这些，迁区就从重构降级为重新部署。

应用不碰个人信息，是不是就不用管辖区了？

大多数情况下可以放宽，但要先确认"不碰个人信息"这个前提本身成立。三类应用通常确实不必纠结辖区：纯静态分发（文档站、安装包、媒体文件）、不含任何可识别信息的计算任务、无个人信息且无合同约束的内部工具。但有几处容易漏：IP 地址、设备标识、账号 ID 在很多辖区都属于个人信息；业务日志里常常夹带用户标识；客服记录里会有联系方式。判断方法不是看你的主业务表，而是看你所有的副本和日志里有没有能识别到人的字段。确认没有之后，辖区就从合规问题退回到纯粹的可用性问题，这时候你完全可以只看用户分布和延迟。

辖区不是玄学，是可以拆成清单的事

回到开头那四张逐字相同的报价单。它们没能告诉你的东西，恰恰是这次决策里唯一重要的东西。价格和配置在四页之间完全退场，于是决策依据只剩下一个：数据放在哪个国家，适用哪套法律，能不能兑现你对客户写下的那句话。

这件事之所以显得玄，是因为很多人把它当成了一个整体判断——"加拿大合规还是美国合规"。拆开之后它一点都不玄：确定机房所属国家与一级行政区、给数据分类、列全所有副本、核对合同原文、把结论写成一句可交付的话、留痕。六步走完，辖区就从一个模糊的顾虑，变成了一份带勾选框的清单。

还有一点值得记住：辖区选择不是下单那一刻的动作，而是贯穿整个架构的动作。主库选对了但备份跨了区，等于没选；应用在加拿大但库在美国，等于没选；数据存对了但第三方分析服务把日志传走了，也等于没选。所以真正该问的从来不是"选哪个城市"，而是"我的数据有几个副本，它们各自在哪个国家"。

蒙特利尔这条线上，下单前要先问法务的三个问题

第一个问题：这批数据里有没有个人信息，有没有属于魁北克本地客户的个人信息。答案直接决定蒙特利尔是不是必选项，还是只是一个可选项。如果客户群体在魁北克，或合同里已经出现数据存放地的表述，这个节点就从"可以考虑"变成"必须考虑"。

第二个问题：合同或客户的采购问卷里，对数据存放地是怎么写的。写的是"加拿大境内"还是"不得出境"，两者的技术含义不同：前者要求主副本都在加拿大境内，后者还要求备份、日志、第三方集成都不能跨出去。法务给出的是义务，工程要把它翻译成节点清单和副本清单。

第三个问题：需不需要法语版本的告知文件，需不需要指定隐私负责人。这两项都不属于服务器配置，但它们会在项目后期变成阻塞项。提前问清楚，比上线前临时补要省事得多。蒙特利尔云页面的报价与档位以官网实时价为准，具体以签约时最新报价与合同为准。

报价相同的四个城市：什么时候不该只看价格

当四张报价单逐字相同的时候，价格已经不携带任何决策信息了——这时候继续盯着价格看，是在一个没有信号的频道上找信号。真正该切换频道的时刻有三个：当客户开始问"数据存在哪个国家"时，当合同里出现数据存放地条款时，当你的用户集中在某个特定省份或州、且当地对数据出境有明确期待时。

反过来，也有完全不必切换到辖区频道的场景：纯静态分发、不含任何可识别信息的计算、无合同约束的内部工具。这些场景下四个城市对你而言确实等价，那就老老实实按用户分布、骨干路径和可用性来选，不要给自己加戏。

区分这两类场景，比记住任何一条法律条文都重要。辖区不是所有业务都要考虑的事，但它是"一旦踩上就必须答对"的事。蒙特利尔这条线（1G 端口线 99 / 199 / 299 / 399 元/月，100M 端口线 299 / 599 / 799 / 1299 元/月，与波特兰、南卡罗莱纳、拉斯维加斯三页逐字相同，以官网实时价为准）的意义，正在于它把这个问题摆到了台面上：页面给不了你答案的时候，你得自己去问。

数据来源：本文所涉配置与价格来自一万网络官网加拿大蒙特利尔云（https://www.idc10000.net/mengtelieryun）、美国波特兰云（https://www.idc10000.net/botelanyun）、美国南卡罗莱纳云（https://www.idc10000.net/nankaluolainayun）、美国拉斯维加斯云（https://www.idc10000.net/lasiweijiasiyun）及美国洛杉矶云（https://www.idc10000.net/luoshanjiyun）页面，更多节点与产品信息见 https://www.idc10000.net/ 。价格与配置随官网调整，具体以签约时最新报价与合同为准。法律部分仅为技术部署视角的通用介绍，不构成法律意见，具体合规判断请咨询专业法务或合规顾问。