美国西海岸三座城市在地图上离得不远，海缆落地却不是同一处。西雅图靠近若干跨太平洋海缆的北美落地，洛杉矶更靠近南向的北美西岸人口，硅谷的机柜密度高，适合把计算和东西向流量放在同一园区。搜美国服务器时如果只写「加州」，会把这三件事买成一件。当前西雅图入门独立服务器是 西雅图服务器 US-SEA-E5-2620，双路是 美国服务器 US-SEA-E5-2620x2。带清洗峰值的是 西雅图高防服务器，多地址是 西雅图站群服务器，核数更高的双路 Gold 是 西雅图 Gold 独立服务器。
到亚洲省不下那 100 毫秒，到东京可以差一截
规划量级：西雅图到东京常见 90 到 120 毫秒，洛杉矶到东京常见 110 到 140 毫秒。差的是海缆走向，不是市区出租车要开多久。到中国大陆，西雅图、洛杉矶、硅谷都落在大约 140 到 200 毫秒这一档，换一座美国城市省不掉这 100 毫秒以上的跨洋预算。大陆买家的页面和回调仍应放 香港服务器 或台北，美国这台只承接北美页面、下载和给北美用户的接口。
北美西海岸自己的用户，洛杉矶和西雅图都够用，按用户更靠近哪边放页面。洛杉矶服务器 US-LA-E5-2620 适合已经把地址和带宽规划在南加州的站点。硅谷适合计算和本地磁盘更重的任务，防御型号见 硅谷独立服务器 US-SV-DEF-E5-2620。不要为了「再买一台美国机更保险」，在三个城市各放一份会写订单的库。三地同时写，故障时无法决定以哪一份为准。
高防和站群是角色，不是时延产品
西雅图高防服务器增加的是清洗容量，业务带宽仍要单独看。清洗和业务端口是两套数字，说明见 高防服务器的两套带宽。西雅图站群服务器增加的是地址数量，跨太平洋的时延不会因为 IP 变多而下降。洛杉矶怎么承接北美页面，见 美国服务器放洛杉矶。硅谷从 E3 到 EPYC 的角色划分，见 硅谷独立服务器怎么选。三篇一起看，才能决定这台美国机器是页面、计算还是清洗入口。
验收时分别从东京、从美国西海岸宽带、从大陆运营商打到这台机器，记录 TCP 首字节，不要三组数字混成一个平均值。东京样本差、美国本地样本好，说明海缆方向符合预期，不必把机器从西雅图搬到洛杉矶。大陆样本差，这是跨洋预算，应把大陆入口移回香港，而不是把西雅图的端口从 100M 升到 1G。升端口解决的是拥塞，不解决距离。
西海岸本地样本可以选旧金山和洛杉矶各一条宽带，访问放在西雅图的页面。若洛杉矶用户访问西雅图比访问洛杉矶机器慢出 20 毫秒以上，而你的用户主要在南加州，页面应改放到 洛杉矶独立服务器。若两边差距在几毫秒到十几毫秒，就按机房库存和地址规划选，不必为了地图上的南北来回折腾。到东京的对比同样要固定目标，例如同一台东京上的探测页。今天测西雅图、下周测洛杉矶，中间如果东京那端也换了线路，两个数字不能横比。
计算任务，编译、转码、队列，可以留在硅谷或西雅图，和页面分开。计算完成后再把结果同步到离用户近的文件节点，用户下载不走计算那台的小端口。西雅图双路 Gold 适合核数已经打满的计算，不适合用来缩短大陆用户的首字节。大陆入口的容量不够时，加的是香港那台的业务带宽或云上的页面层。工单里写三行结论即可：到东京的中位数、到西海岸本地的中位数、到大陆的中位数。三行齐了，城市才算选完。
三行数字建议附上测试点的运营商和时段。西雅图早高峰和东京晚高峰不是同一时刻，跨太平洋的拥塞往往出现在线路两端各自的晚上。只在北京时间下午测一轮，可能正好错过两端的忙时，得出「三座城市都差不多」的错觉。补测时把北京时间 21 点和太平洋时间晚上各留一轮。文件同步如果走公网，把同步窗口放在两端都不忙的时段。同步流量和用户下载挤在同一个小端口上，用户侧的首字节会先变差，看起来像海缆突然变长。