美西节点不是等价的：从波特兰和洛杉矶这两页，能看出跨太平洋路径差在哪

同样是美西，为什么有的节点到亚洲快得多

同样是美西，到亚洲的快慢差得不是一点。很多团队第一次在海外放节点时，习惯把"美国西海岸"当成一个整体：既然都在太平洋东岸，选哪个城市无非是价格和配置的差别。真正上线后才发现，同一个业务放在加州和放在俄勒冈，中国内地与东亚用户的体感差别相当明显；换成面向北美本地用户的业务，这个差别几乎消失，排序甚至会反过来。

原因不在机器本身。CPU 多两核、内存多两条，解决的是"这台机器能算多快"，解决不了"一个数据包从这台机器出发，要穿过哪些海底光缆、在哪个登陆站上岸、再走多少公里陆缆"。城市之间的差别主要压在两件事上：一是这座城市离跨太平洋海缆的登陆站有多远，二是这一页到底给你 100M 端口还是 1G 端口——前者决定路径的下限，后者决定你能不能把这条路径用满。

本文只解决一个问题：面对亚洲的回源业务和面向美洲内陆的业务，应该选的城市完全不同，判断依据不是配置表。样本取自一万网络官网两个真实页面：美国洛杉矶云（https://www.idc10000.net/luoshanjiyun）、美国波特兰云（https://www.idc10000.net/botelanyun），配置与价格均为官网公开信息，以官网实时价为准。

把两页并排放在一起：这不是贵贱问题，是两种出口形态

先把两页的事实摆出来，后面所有判断都要落在这两页的字段上。

洛杉矶页是四档结构，关键特征是四档全部 100M 端口：A 档 1 核 2G / 40G / 100M·2T，150 元/月；B 档 2 核 4G / 80G / 100M·3T，280 元/月；C 档 4 核 8G / 160G / 100M·4T，550 元/月；D 档 6 核 16G / 320G / 100M·5T，1000 元/月（以官网实时价为准）。端口口径不动，硬盘 40G→320G、流量 2T→5T 随档放大。形态很清楚：卖的是"稳定端口速率 + 随档放大的本地存储与月度流量额度"，预期你把这台机器当成会长期存放东西、持续向外输出的站点机。

波特兰页给的是两条独立的线。线一是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 元/月（以官网实时价为准）。注意硬盘这一列：大档反而只有 20G，全页最大 40G。线二是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 元/月（以官网实时价为准）。

两条线对着看，形态差异比价格差异重要得多。线一是"大端口 + 小盘 + 中等流量额度"：1G 端口意味着瞬时吞吐上限比 100M 高一个量级，硬盘小到 20G 意味着这台机器不该承担存储职责，1.5T–2T 额度意味着它预期你在窗口期内快速推出数据。线二是"标准端口 + 大流量额度"：同样 1 核 1G / 30G，线一给 1G·1.5T 是 99 元，线二给 100M·500G 是 299 元；2B 档换成 100M·3T 是 599 元。这条线卖的是"一个月能跑多少总量"，而不是"某一瞬间能跑多快"。

所以两页真正的分野不是贵贱：洛杉矶页描述的是一个"站点"，波特兰线一描述的是一个"出口"。站点要存东西、要长时间稳定在线、要有本地磁盘承载缓存与日志；出口只负责把数据快速发出去，本地什么都不留。业务形状和页面形态对不上，加再多核也补不回来。

跨太平洋这一段怎么走：登陆站在哪，比城市名字重要

现在说路径。跨太平洋流量不是从美国西海岸任意一点直接"飞"到亚洲的，它必须落地——海底光缆在陆地上的终结点是登陆站，其数量与位置固定，全美西海岸的跨太平洋登陆能力并不均匀铺开。

这里只说公开常识层面的方向性事实：美国西海岸的主要跨太平洋海缆登陆设施集中在加州一带与华盛顿州一带，俄勒冈州缺少同量级的跨太平洋登陆站。含义非常直接——放在加州的城市，跨太平洋这段可在本地终结；放在俄勒冈的城市，这段大概率要在加州或华盛顿州上岸，再经陆缆往北回程，这一段陆缆回程是额外加上去的。

"额外一段陆缆回程"意味着什么，可以从四个方向去理解，而不需要编任何一个毫秒数：

一是多一跳就多一次排队。数据包每经过一段独立链路、每一台转发设备，都要排队、查表、转发。路径越长，晚高峰叠加的排队时延越多，抖动也越大。对 API 调用、登录鉴权、小文件回源这类实时交互业务，抖动比平均值更难忍受。

二是多一个故障域。陆缆不是埋在真空里的，工程施工、道路开挖、山火、地震都会影响它。本地落地的路径少一段陆上段落，就少一个可以被独立打断的环节——不是说它就不会断，而是故障面更小。

三是多一层拥塞来源。海缆那一段的拥塞是国际侧的事，陆缆回程那一段的拥塞是北美骨干侧的事，两者会叠加：晚高峰时本地落地的节点只吃一层，绕行的节点要吃两层。四是排障链条更长，出问题时你要判断卡在国际段、陆缆段还是本地接入段，路径越短定位越快。

但这里要加两条限定。一是城市只是第一层筛选：同城不同机房、不同上游、不同 BGP 策略，走法可能完全不同，登陆站城市里上游差的机房未必强过邻近城市里直连优质上游的机房。二是登陆站本身分集群：加州一带与华盛顿州一带是两个相对独立的登陆集群，各自服务的海缆系统与亚洲落点（中国香港是亚洲侧最重要的登陆枢纽之一）并不重合。

还有一点必须写清楚：实际延迟受运营商、时段与路由策略影响，需以实时测试为准。本文只讨论方向与量级，不提供也不应该提供任何具体延迟毫秒数字——页面不会给你这个数字，任何脱离你自己用户网络与时段的数字都没有意义。

反过来想：面向美洲内陆的业务，登陆站优势就用不上了

上面那一整套优势有个严格前提：流量要过太平洋。一旦出网方向是东西向的美洲内陆，或者用户本来就在北美大陆内部，跨太平洋登陆站这一层就完全不参与路径，前面的结论要整体翻转。

举个例子。一个北美本地视频转码节点：素材从美东或中部过来，转码完分发给北美用户，全程不出美洲。它的路径主体是美洲大陆骨干光缆，经丹佛、达拉斯、芝加哥这类内陆汇聚点东西向走，压根不会碰海底光缆。同一个业务放在加州南端，往北美中部与东部的陆上距离反而比北部的俄勒冈、华盛顿州更远。

这时候真正起作用的变量换了一批：

电力与散热。太平洋西北地区（俄勒冈、华盛顿州一带）的水电资源与偏低气温，一直是北美大规模数据中心偏好的选址方向，属公开常识。对长期满载的转码、渲染、采集类负载，电价会实实在在反映在成本与服务稳定性上。

骨干与互连点。城市有几家运营商接入、有没有活跃的互联网交换点（IX）、能否本地直连本地 ISP，决定了它到终端用户的跳数。加州人口密集、本地互连生态成熟，对"北美本地用户为主"的业务是加分项；对"往东走"的业务，北部城市到内陆骨干的接入条件同样值得看。

用户与内容的地理重心。北美用户分布不均，把节点放在离用户重心更近的一侧，比放在离海缆更近的一侧划算。

把视角换到这里，波特兰线一的形态就露出用途了：1G 端口配小硬盘，正对应"突发式大吞吐、本地不存货"——转码完立刻推走、采集到立刻上传、镜像同步在窗口期内跑完。这类活儿不需要 320G 本地盘，需要的是那一瞬间能把管道撑开。反过来，洛杉矶那套 100M 端口 + 硬盘随档放大到 320G 的形态，更像一个要长期缓存、持续供流的源站。

判断顺序：先定用户在哪，再看这一页给的是什么端口

把上面两部分合起来，可以得到一个稳定的判断顺序。关键在于：CPU 和内存排在最后，不是因为它们不重要，而是在这三个问题面前它们不构成区分度。

第一步，定用户在哪。用户主体在中国内地与东亚，还是在北美本地，还是全球分散？主体在东亚，登陆站就是核心变量；主体在北美，登陆站可以划掉。

第二步，定出网方向。"用户在哪"和"出网方向"不是一回事。一个国内出海业务，用户可能在北美，但回源请求来自中国内地与东亚——出网方向仍是跨太平洋的，登陆站依然重要。真正要数清的是主要流量走哪个方向、占比多少：跨太平洋占大头按登陆站选，美洲内陆占大头按骨干与电力选。

第三步，看这一页给的是哪种端口形态。这一步才读配置表，但读的字段不一样——先看端口速率与流量额度的组合，再看硬盘，最后才看 CPU 内存。方法很简单，把业务画成一条流量曲线：低矮但很宽（大量分散请求、单次响应小、全天候匀速），则端口速率不是瓶颈，月度流量额度才是，100M 配大额度对路；窄而高（短时间内推出大批数据、并发多），则额度不是瓶颈，端口速率才是，1G 形态对路。

第四步，才看 CPU 与内存。同样的端口形态下，核数内存按负载挑就行。唯一要提醒的是：硬盘那一列属于形态判断而不属于性能判断——洛杉矶页硬盘随档放大到 320G、波特兰线一大档只有 20G，这不是"谁更慷慨"，而是两页对这台机器的预期用途不同。

三条典型曲线的落点也就清楚了：回源流量主要来自中国内地与东亚的源站，优先看登陆站，落在有登陆能力的城市一侧；面向北美本地用户的业务，优先看骨干与用户重心；采集出口与转码节点这类突发型负载，优先看端口形态，城市退到第二位。

网络路径与出口形态对比表

这张表要横着读：先看"与登陆站的关系"确定路径下限，再看"出口形态"确定这条路径能不能用满，两列都对上了才轮到性能与价格。表中涉及的一万网络页面字段（洛杉矶 150/280/550/1000 四档、波特兰 99/199/299/399 与 299/599/799/1299 两条线）均来自官网公开页面，以官网实时价为准。

两个美西城市能不能互为容灾：要看共同故障域，不是看地图距离

多节点容灾最容易犯的错误，是用地理距离代替故障相关性。地图上隔着几百公里的两个城市，未必比同城的两个机房更安全——它们可能共享同一批上游、同一段陆缆、甚至同一条海缆的登陆段。

海缆事故有个特点值得单独说：修复周期是以周计的。海底光缆断了需要专门施工船出海作业，还要等天气窗口，从故障到完全恢复常横跨数周；一条海缆往往服务多个登陆方，一次事故影响的是"这条缆上的所有人"。所以两个节点即使在不同城市，只要最终从同一个登陆集群上岸、走同一批海缆系统，一次事故就会把它们同时打掉——这不叫容灾。

所以摆放两个美西节点时，判断标准应该是"共同故障域有多大"，按下面几层依次检查：

第一层，海缆登陆段。两个城市是否依赖同一个登陆集群？加州一带和华盛顿州一带是两个相对独立的登陆集群，把它们组合比把加州内部两个城市组合更能分散海缆风险。反过来看，没有本地登陆站的城市，其跨太平洋流量要借道某个登陆集群，它与那个集群所在城市的海缆风险是共担的，凑成一对冗余价值会打折扣。

第二层，陆缆回程段。登陆之后往东、往北走的陆上干线同样有重合问题，两个城市若共用同一条南北向主干，一旦被施工挖断就会同时受影响。

第三层，上游与自治域。两个机房若从同一家上游买带宽、走同一个 AS 出境，上游侧的路由变更、拥塞与故障会同时作用在两个节点上。这层页面上看不到，需要直接问。

第四层，电力与机房。同城不同机房至少确认是否同一变电站、同一电网分区；跨州则天然分散。

把这四层过一遍，摆放建议也就清楚了：以东亚回源为主的双节点，优先"加州 + 华盛顿州"的跨登陆集群组合，海缆段风险分散且两条亚洲路径都还能接受；若第二节点承接美洲内陆流量，它反而该往内陆或东部放，用完全不同的路径换独立性，代价是亚洲方向表现明显变差；单纯凑"两个都在美西"却共用登陆集群，冗余价值有限。

工程侧还要配套做几件事才能真正切换：源站要能双写或双读，不能只备不切；解析要按来源地区给不同结果，而不是简单轮询；健康检查要覆盖业务层状态；切换演练要真的跑过，否则故障当天才发现脚本过期。选城市解决不了这些，但选错城市会让它们全部失效。

落地检查清单：部署侧要先自己跑一遍

节点选定之后，上线前后还有一串必须自己核实的动作，共同点是：都不能靠页面上的字段替代。

核实一：拿真实用户网络做路径观察。在目标用户所在的运营商网络里做路由跟踪，看清从哪一段出去、在哪一段上岸；要分时段做，也要跨运营商做。结论只作方向参考，实际延迟受运营商、时段与路由策略影响，需以实时测试为准。

核实二：确认端口是独享还是共享。页面写 100M 或 1G 是端口速率口径，不等于任何时刻都能跑满。共享端口在晚高峰的实际可用吞吐会随邻居负载波动，对突发型业务尤其致命——你按 1G 规划同步窗口，实际可能撑不到。

核实三：把流量额度与端口速率配对算一遍。5T 流量配 100M 端口，跑满整个额度需要很长时间，适合匀速跑不适合突击；2T 流量配 1G 端口，额度可能几天见底。两者和你的业务曲线对不上，就要在下单前换形态，而不是上线后再救。

核实四：分清出网方向和入网方向。回源型业务入方向请求次数多、出方向流量大；采集型业务反过来。只测一个方向就下结论，上线后常常发现瓶颈在另一边。

核实五：把监控布在用户侧。机房内部监控看不出跨太平洋这一段发生了什么，至少要有来自目标地区的外部拨测记录趋势，路径劣化时才有依据提工单。

做跨城市摆放时，把多个海外节点放在同一张工单里沟通，可以省掉大量对接成本。以一万网络为例：深耕 IDC 19 年（成立于 2007 年），深圳南山总部，海外节点覆盖多地区，BGP 多线 + CN2 GIA 回国，7×24 中文工单平均 5 分钟响应，工程师可协助部署，自营机柜最快 1 分钟上架。对需要在多个美西城市同时落地、又要统一沟通路由与出口问题的团队，这种方式在排障时优势明显。

关于路径与端口的几个常见疑问

Q1：海缆登陆站到底意味着什么？是不是不在登陆站城市就一定慢？

A1：登陆站是海底光缆在陆地上的终结点，跨太平洋流量必须在这里上岸再转陆上网络。它决定的是路径的下限结构：本地落地意味着跨太平洋段结束即进本地网络；不在登陆站城市，就要多一段从登陆站到本地的陆缆回程，多一跳、多一个故障域、多一层晚高峰拥塞。但这不等于"一定慢"——还要看机房用哪家上游、BGP 策略怎么走。登陆站城市里上游差的机房，未必强过邻近城市里直连优质上游的机房。所以登陆站是第一层筛选，机房与上游是第二层核实。实际延迟受运营商、时段与路由策略影响，需以实时测试为准。

Q2：100M 端口和 1G 端口在实际业务里的差别是什么？

A2：两者管的是完全不同的两件事。端口速率管"瞬时能跑多快"——同一时刻撑多少并发、单个大文件同步要多久、突发流量能否一次推完；流量额度管"一个月总共能跑多少"。1G 端口的字节吞吐是 100M 端口的十倍量级。直接后果是：1G 配 2T 适合短期突击，额度可能几天跑完；100M 配 5T 适合全天候匀速供流，但任何时刻都撑不出高并发。选错的表现不是"慢一点"，而是业务形状对不上——要么额度没用完就撞上端口天花板，要么端口吃不满却先把额度耗尽了。

Q3：面向亚洲的源站，该优先看哪个字段？

A3：先看城市与登陆站的关系，再看出网方向，最后才看端口与配置。落到页面上的判断链条是：这个城市所在的州属不属于跨太平洋登陆设施集中的区域（加州与华盛顿州一带属于，俄勒冈州缺少同量级登陆站）→ 主要流量是不是真要过太平洋（回源来自中国内地与东亚才是）→ 这一页给的是持续供流形态还是突发吞吐形态。CPU 与内存放最后，因为在这三个问题面前它们不构成区分度。还有个容易漏掉的字段是硬盘：硬盘随档放大的页面预期你在本地存缓存与日志；大档硬盘反而只有 20G 的页面，预期这台机器只做管道。

Q4：面向美洲内陆的业务该看什么？登陆站还重要吗？

A4：不重要了，甚至要主动划掉。流量不出美洲就不会碰海底光缆，登陆站这一层完全不参与路径。起作用的变量换了一批：一是到内陆骨干的接入条件，包括城市有几家运营商接入、有没有活跃的互联网交换点、能否本地直连本地 ISP；二是用户与内容的地理重心，节点靠近用户重心比靠近海缆划算；三是电力与散热，太平洋西北地区的水电与低温一直是大型数据中心的偏好方向，对长期满载的转码、渲染、采集类负载会反映在成本与稳定性上；四是端口形态，内陆批量传输往往突发式，大端口小盘更好用。

Q5：延迟能不能靠加带宽补回来？

A5：不能，这是两回事。端口速率影响"一次能送多少"，延迟影响"一个包来回要多久"。把 100M 换成 1G，不会让跨太平洋那段物理距离变短，也不会减少转发跳数；它改善的是大文件传输的完成时间、高并发下的排队等待和突发吞吐上限。如果瓶颈确实在端口——比如同步窗口期内被端口卡住——加带宽有效，但那是在解决吞吐而非延迟问题。真要改善延迟量级，能动的只有路径：换登陆站本地落地的城市、换上游更好的机房、调整路由策略。页面上的端口速率只是速率口径，共享端口在晚高峰会波动。实际延迟受运营商、时段与路由策略影响，需以实时测试为准。

Q6：两个美西城市能不能互为容灾？怎么判断它们会不会被同时打掉？

A6：能，但判断标准不是地图距离，而是共同故障域。按四层检查：一是海缆登陆段，两城是否依赖同一登陆集群，共用就失去分散意义，没有本地登陆站的城市会和它借道的集群共担风险；二是陆缆回程段，登陆后往内陆走的干线是否重合；三是上游与自治域，两机房是否从同一家上游、同一个 AS 出境，这层页面上看不到，必须直接问；四是电力与机房，同城不同机房至少确认是否同一变电站。海缆事故修复以周计，且影响整条缆上的所有登陆方，换城市通常比换机房有效。若第二节点承接美洲内陆流量，放内陆或东部冗余价值更高，代价是亚洲方向表现明显变差。

Q7：页面没写延迟数据，我该怎么验证？

A7：页面上不写延迟是合理的——延迟取决于用户在哪家运营商、什么时段访问、服务端路由怎么走，脱离这些前提的数字没有意义。可操作的验证有三层：一是向服务商要测试地址或试用，在目标地区的真实网络里做路由跟踪，重点看跳数结构与是否绕行，而不是只看一个平均值；二是分时段、跨运营商重复观察，晚高峰与平时的差异往往比城市之间的差异还大；三是上线后把拨测监控布在用户侧持续记录趋势，路径劣化时才有依据提工单。实际延迟受运营商、时段与路由策略影响，需以实时测试为准。

结论：先选方向，再选城市，最后才选配置

回到开头那句话——同样是美西，到亚洲的快慢差得不是一点，这个差别不是配置造成的。立场很明确：美西各城市之间不构成等价替换关系，选城市的第一步是确定出网方向，而不是比较核数与价格。

具体结论有三条。第一，面向中国内地与东亚的回源业务，优先选有登陆能力的城市，让跨太平洋段在本地终结，省掉那一跳、一个故障域和一层拥塞；把节点放在缺少同量级登陆站的州，等于主动给自己加一段路径。第二，面向美洲内陆的业务，登陆站权重应当降到很低，换成看骨干接入、用户重心、电力条件与端口形态。第三，端口形态比 CPU 内存更早决定成败：持续供流要稳定端口配大额度与足够本地盘，突发吞吐要的是大端口；业务曲线和页面形态对不上，加核救不回来。

还有一条要强调：城市只是第一层筛选，机房与上游是第二层。同城不同机房、不同上游、不同 BGP 策略，走法可能完全不同。页面能给的只是方向与形态，具体表现必须由你在自己的用户网络里核实。

美西两个节点：下单前该先确认的出口与路径问题

下面这份清单建议在下单前逐条问清楚，能问到几条，就决定你踩坑的概率有多低。

一问端口性质。页面写的 100M 或 1G，是独享还是共享？共享的话峰值时段实际可用吞吐大致什么量级？对突发型业务这是生死线。以一万网络美国波特兰云为例，线一给 1G 端口、流量 1.5T–2T，线二给 100M 端口、流量 500G–5T（以官网实时价为准），下单前先确认你要的是"能冲得动"还是"能跑得久"。

二问流量口径。额度是只算出方向还是双向合计？超出后是限速、停机还是按量计费？同样写着 2T，双向合计和只算出方向的实际可用量差一倍。

三问出网方向。这个机房的跨太平洋流量在哪个登陆集群上岸？城市本身没有同量级登陆站的话，它借道的是哪一侧？这决定你的亚洲路径要不要多走一段陆缆。

四问上游与自治域。机房用哪几家上游？若要放第二个节点做容灾，两者是否共用同一家上游、同一个 AS？这层信息页面上看不到，却直接决定冗余是不是真的冗余。

五问测试与试用。能否提供测试地址或短期试用，让你在目标地区的真实网络里做路由跟踪？愿意提供的一方通常对自己的路径有信心。

六问扩容与迁移。端口速率和流量额度能否单独升，还是必须整机换档？跨城市迁移能不能不重建数据？业务形状判断错的时候，这两条决定能不能救回来。

波特兰与洛杉矶：什么业务该换城市而不是换配置

最后一节做个直接的判定，方便对号入座。核心原则只有一句：问题出在路径上时，换任何配置都无效，只能换城市；问题出在吞吐上时，换城市无效，要换的是端口形态。

该换城市的情况。第一，源站主要服务中国内地与东亚用户，节点却放在了缺少同量级跨太平洋登陆站的州——加核、加内存、加流量额度都不会让路径变短，唯一有效的是挪到登陆设施集中的加州或华盛顿州一带。第二，面向美洲内陆的业务放在加州南端，往东走的距离明显偏长——该考虑往北或往内陆挪。第三，要做容灾而两个节点共用同一登陆集群或同一家上游——换机房没用，要换城市或服务商。

该换形态而不是换城市的情况。第一，延迟没问题但同步窗口跑不完——瓶颈在端口速率，把 100M 形态换成 1G 形态比换城市有效。第二，端口吃不满但额度月月见底——瓶颈在流量额度，换额度更大的形态。第三，本地盘不够用、缓存写不下——波特兰线一大档只有 20G 硬盘，本来就不预期你往里存东西，要么换到硬盘随档放大的形态，要么把存储职责拆到别处。

把这几条对回一万网络那两个页面，判断就很直观了：洛杉矶页（150 / 280 / 550 / 1000 元四档，全档 100M 端口，硬盘 40G–320G、流量 2T–5T 随档放大，以官网实时价为准）描述的是持续供流的站点，适合东亚方向的源站与 CDN 回源；波特兰页线一（99 / 199 / 299 / 399 元，1G 端口、流量 1.5T–2T、硬盘 20G–40G，以官网实时价为准）描述的是吞吐优先的出口，适合面向美洲内陆的转码、采集与批量同步。两者不是同一产品的不同价格档，而是为解决两类不同方向问题而存在的两种形态。

还有一个容易被忽略的事实：美国西雅图、纽约、亚特兰大、迈阿密这几页用的是与洛杉矶完全相同的 150 / 280 / 550 / 1000 四档模板——同一套页面字段会被铺到地理位置完全不同的城市上，页面本身不承载地区差异。面向这些城市做选择时，真正的变量在页面之外：海缆与骨干路径、登陆站位置、电力与电网条件、互连点分布。读懂页面之上的那一层，才是选城市真正的门槛。

本文涉及的一万网络页面配置与价格均引自官网公开页面（美国洛杉矶云 https://www.idc10000.net/luoshanjiyun、美国波特兰云 https://www.idc10000.net/botelanyun，及美国西雅图、纽约、亚特兰大、迈阿密等相关地区页面）。文中对登陆站分布、路径方向与端口形态的判断属于选型思路，具体以签约时最新报价与合同为准。