美国住宅IP VPS测评:NovixLink 洛杉矶 NTT 实测
买美国住宅IP VPS的人,最后多半卡在同一个地方:商家嘴里的「住宅IP」,到底是不是你脑子里那个「住宅」。 一位做 TikTok 的朋友纠结了半个月:账号总被判成数据中心流量,他问换住宅IP 是不是就一劳永逸;另一位读者更郁闷,下单时买的是「美国家庭宽带」,到手一查 IP 归属,落在运营商自己的段上,跟 Cox、Comcast 那种真正的家庭宽带根本不是一回事。
这次我们不打嘴仗,直接用一台真机把这件事测出来。NovixLink(诺联主机)LAX-CUPN 线路提供了一台测试机,IP 为 192.220.2.210。本文所有数据都来自这一台机器、同一时段:真机内的 dd / CPU / 带宽 / 出口探测,加上中国大陆两个只读探测源与美国洛杉矶一个探测源对它的 ping 与 tracepath。

先给结论:这是一台 KVM 真虚拟化、1 核 AMD EPYC 7K62、956 MB 内存的机器,磁盘顺序写 296 MB/s,Cachefly 单线程下行 14.93 MB/s ≈ 119 Mbps;广东电信 165.122 ms、阿里云北京 169.107 ms,两个源 20 包均 0% 丢包。而它的 IP 经五源一致判定加 ARIN 与 NTT 官方 geofeed 两级溯源,确认为 AS2914 NTT America 的 ISP 段——按 NovixLink 官网 FAQ 的定义,它属于「住宅IP」档,不是消费者家宽 IP。
这次没测到什么,也一并写在前面:未跑 UnixBench 与 fio,所以没有跑分、没有 IOPS;未做多时段采样,所以没有晚高峰数据;国内只有广东电信与阿里云北京两个源,没有联通与移动,所以全文只写「双源」;无 IPv6 数据;流媒体只验到 HTTP 状态码,未做实际播放;本文不写价格与优惠码。
一、这台机器是什么:先把身份钉死
| 项目 | 实测值 |
|---|---|
| 系统 | Ubuntu 26.04.1 LTS |
| 内核 | 7.0.0-34 |
| 虚拟化 | KVM 真虚拟化(非容器、非 LXC) |
| CPU | 1 核 AMD EPYC 7K62 |
| 内存 | 956 MB 内存 + 1G swap |
| 磁盘 | vda 10G,可用 8.6G |
| 拥塞控制 | BBR + fq 已开 |
| 反向 DNS | ipinfo 未返回 hostname(无 rDNS) |
真正值得单独说的是工具链。实测 gcc=no cc=no make=no git=no,只有 openssl=yes apt-get=yes dpkg=yes(apt 3.2.0)。也就是说:这台机器开箱不能编译,也不能直接 git clone。要装任何需要源码构建的组件,得先自己 apt-get install build-essential 与 git。
这一点几乎没人写,但它恰恰是决策信息:如果你打算在这台机器上编译 nginx、跑 Go 项目或装某些需要 make 的代理组件,请把它算进部署成本里。956 MB 内存配 1G swap 也说明它是轻量定位——内存吃紧时会落到 swap 上,别指望它扛数据库或大内存应用。
换句话说,一台美国住宅IP VPS 的硬件配置往往不是它的卖点,段位属性才是。所以看这类产品时,值得先把配置当成约束条件读(哪些跑不动),再把 IP 当成价值本身读(它到底属于谁的段)。本文后面几节就是按这个顺序展开的。
二、性能实测:磁盘与 CPU
2.1 磁盘:两组 dd,口径要说清
| 项目 | 命令 | 实测输出 |
|---|---|---|
| 顺序写 | dd if=/dev/zero of=./.ddtest bs=1M count=1024 oflag=direct |
1073741824 bytes copied, 3.62789 s, 296 MB/s |
| 4k + fdatasync | dd bs=4k count=20000 conv=fdatasync |
81920000 bytes (82 MB, 78 MiB) copied, 0.233494 s, 352 MB/s |
| 顺序读 | dd if=./.ddtest of=/dev/null bs=1M iflag=direct |
dd: IO error: Invalid input(本次未取得) |
两点必须讲明白,否则这两行数字会被读错:
- 352 MB/s 这一项是「带 fdatasync 的 4k 块顺序写吞吐」,不是 4K 随机 IOPS。
conv=fdatasync的作用是每次写完后强制刷盘,它衡量的是顺序写的落盘能力,不能换算成随机读写 IOPS。本次未跑 fio,所以本文不提供任何 IOPS 数字。 - 读的那一项没有测到。
iflag=direct在这台机器上直接报Invalid input,我们如实记为「未取得」,不用写的值去补空。
2.2 CPU:两个微基准,不下强弱结论
| 微基准 | 实测耗时 |
|---|---|
Python fib(30) |
0.117 s |
| sha256 循环 200000 次 | 0.141 s |
空载时 /proc/loadavg 为 0.29 0.19 0.11 1/103 3970。
这两个数只回答一件事:单核的整型递归与哈希吞吐处在什么量级。它们不代表综合性能,本次也没有跑 UnixBench,所以本文不给跑分、不下「性能强 / 性能弱」的结论。同时,这组数字只做本机内部解读——不同商家不是同机同口径,本文不做任何横向对比。
2.3 怎么读这组数字
三个提醒:第一,微基准只覆盖它测到的那一件事。fib(30) 考察递归与函数调用开销,sha256 循环考察哈希与内存读写,两者都测不到多核调度、磁盘并发、网络栈这些真正决定体感的部分。第二,空载 loadavg 0.29 0.19 0.11 1/103 3970 只是基线,它说明测试开始前机器上没有别的重负载,不代表持续负载下的表现。第三,磁盘 296 MB/s 与 352 MB/s 是同一个盘的两种写法:前者是 1M 块直接写,后者是 4k 块带刷盘,块大小与刷盘策略不同,两个数不能直接比高低,更不能拿去和别家的 fio 结果比。把它们理解为「这块盘顺序写吞吐在 300 MB/s 量级」就够了。
最后一句总结:一台美国住宅IP VPS 的性能值不值得看,取决于你的用途是不是 CPU / 磁盘密集型。对多数冲着段位属性去的人来说,上面这些数字的意义是排掉跑不动的场景,而不是证明它跑得有多好。
三、「住宅IP」到底是什么:用 192.220.2.210 反推
这一节是本篇最重要的部分,也是中文圈几乎没人正面回答过的问题:住宅IP 和家宽 IP 到底是不是一回事。
先讲那位读者的经历。他买的时候商品页写「美国家宽」,拿到机器去查,IP 落在一家 Tier-1 运营商的段上。他去问客服,客服说「这就是我们的住宅IP」。双方说的其实都没错,错的是两个中文词被混用了。
3.1 第一级:五个 IP 库一致判 AS2914
| 溯源层级 | 来源 | 结论 |
|---|---|---|
| 商业库 | ipinfo | org = AS2914 NTT America, Inc.;Los Angeles / California / US;postal 90013;tz America/Los_Angeles;hostname 未返回 |
| 商业库 | ip-api | 一致判 AS2914 |
| 商业库 | ipwho.is | 一致判 AS2914 |
| 风险库 | proxycheck | 一致判 AS2914;用途分类 Business;risk 0;proxy=no |
| 商业库 | ipregistry | 一致判 AS2914;type="isp" |
五源全部指向 AS2914 NTT America,位置一致指向洛杉矶(postal 90013)。这里有个容易踩的坑:proxycheck 给的 「Business」 是用途分类,ipregistry 给的 type="isp" 是地址类型分类,二者不在同一个维度上,不能反过来读成「其实不是住宅IP」——反向夸大同样是夸大。
3.2 第二、三级:ARIN 登记与 NTT 官方 geofeed
商业库只是第三方判断,往上还有两级硬证据:
- ARIN 把
192.220.0.0/16登记为 Direct Allocation 给 NTT America。 这是地址段的注册归属,不是任何第三方库的推测。 - NTT 官方 geofeed 把该段标注为 US-CA-Los Angeles。 这是运营商自己发布的地理位置数据。
三级证据(商业库 → 注册机构 → 运营商自述)在同一结论上闭合:这个 IP 属于 NTT America 在洛杉矶的 ISP 段,且不是代理出口(proxy=no、risk 0)。
3.3 商家 FAQ 自己怎么定义
NovixLink 官网 FAQ 的表述是:其「住宅IP」来自 NTT / GTT / Cogent 这类 Tier-1 传输商;而「家宽 IP」才是 Cox 等本土家庭宽带。也就是说,在商家的产品语言里,「住宅IP」指的是运营商段位的属性,「家宽 IP」指的是消费者家庭宽带线路。
3.4 结论:本机是「住宅IP」档,不是消费者家宽 IP
把两件事拼起来就闭合了:本机 IP 是 AS2914 NTT America 的 ISP 段(五源 + ARIN + geofeed),而商家 FAQ 明确「住宅IP 来自 NTT / GTT / Cogent」→ 本机落在商家定义的「住宅IP」档内;同时商家 FAQ 明确「家宽 IP 才是 Cox 等本土家庭宽带」→ 本机不是消费者家宽 IP。
这就是本文标题里「美国住宅IP VPS测评」要回答的核心:你买到的「住宅」,是运营商段位的住宅,不是某户人家客厅里的那根宽带。
3.5 中文圈为什么会混淆
原因在英文词:residential、ISP、home broadband 在英文语境里各有分工,译进中文后常被统统塞进「住宅 / 家宽」两个词里。商家为了好卖,也会挑更讨喜的那个词。结果就是同一个段,在这家叫「住宅IP」,在另一家叫「原生 ISP」,在第三家叫「家宽」。
怎么避坑?看 ASN,别看形容词。 拿到机器先查 ASN 与注册归属:落在 Cox / Comcast / AT&T 这类消费者宽带运营商段上,才谈得上家宽;落在 NTT / GTT / Cogent 这类 Tier-1 传输商段上,就是商家说的「住宅IP」。像 192.220.2.210 这样 ARIN 直接登记给 NTT America 的,一查就现形。
「住宅IP和家宽IP的区别」之所以值得单独拆成一节,是因为它直接决定你能拿这台机器做什么:段位属性影响的是风控库对它的归类,而家宽线路影响的是它看起来像不像一户真实家庭。前者靠 ASN 就能验证,后者需要商家明确承诺线路类型。本文只验证了前者。
如果你只是想看这条线现在什么价,NovixLink 国庆价目 里是完整的价目与活动,本文不写价格。
四、国内访问:双源延迟与回程路由
4.1 三源各 20 包,原样给完整统计
口径先说清:**cn- 是「国内探测源访问这台机器」的延迟,us- 是「美国本地探测源访问这台机器」的延迟,两者不是同一件事,不可混写。**
| 探测源 | min/avg/max/mdev(ms) | 丢包 |
|---|---|---|
| 中国广东·电信 AS4816(单线) | 164.246 / 165.122 / 167.161 / 0.645 | 0%(20 包) |
| 中国北京·阿里云 BGP AS37963 | 160.952 / 169.107 / 315.491 / 33.590 | 0%(20 包) |
| 美国洛杉矶·AS402506 | 0.962 / 1.138 / 1.530 / 0.130 | 0%(20 包) |
广东电信 AS4816 的 0.645 ms mdev 说明这批包非常集中。北京阿里云 AS37963 的 mdev 是 33.590 ms,但这个数字是被第 2 包一个 315.491 ms 的尖峰单独拉高的,其余 19 包都在 160–163 ms 之间——所以这里不能写成「抖动大 / 不稳定」,原样给出统计并说明成因才是对的。
另外,0% 丢包是一个时段、20 包的快照,不代表全天或晚高峰的表现,本文没有多时段数据。三个源里,洛杉矶本地的 1.138 ms 平均值说明机器确实在洛杉矶本地网络内,这与 ipinfo 的 postal 90013、NTT geofeed 的 US-CA-Los Angeles 相互印证——选美国住宅IP VPS 时,这条「地理位置三重印证」比任何一个延迟数字都更有参考价值,因为它告诉你的不是快不快,而是它在不在你说的地方。

4.2 路由逐跳:看它经过谁
下表的「归属」一栏全部来自 2026-10-03 对每一跳 IP 逐个做的 ipinfo 查询(骨干网 IP 的地理标注不可信,因此只标 ASN,不标城市)。
广东侧(tracepath -n -m 30,19 跳,pmtu 1500),只列有回应的关键跳:
| 跳 | IP | 该跳 RTT | 归属 |
|---|---|---|---|
| 11 | 110.94.123.198 |
160.364 ms | ipinfo 未返回 org(country=CN) |
| 12 | 218.30.53.51 |
152.883 ms | 中国电信骨干 AS4134 |
| 13 | 129.250.5.24 |
153.820 ms | AS2914 NTT 骨干 |
| 14 | 129.250.4.238 |
159.839 ms | AS2914 NTT 骨干 |
| 15 | 129.250.3.243 |
161.035 ms | AS2914 NTT 骨干 |
| 19 | 192.220.2.210 |
164.250 ms | reached |
第 1、3、4、8 跳也有回应(192.168.247.30、103.45.0.97、103.45.0.53、119.147.220.137),均属探测源本地或城域段;其余跳(第 2/5/6/7/9/10/16/17/18 跳)均为 no reply。
北京侧(18 跳,hops 18 back 19):
| 跳 | IP | 该跳 RTT | 归属 |
|---|---|---|---|
| 10 | 202.97.43.110 |
147.670 ms(asymm 11) | AS4134 |
| 11 | 218.30.53.51 |
149.815 ms | AS4134 |
| 12 | 129.250.5.24 |
152.226 ms | AS2914 NTT 骨干 |
| 13 | 129.250.4.238 |
155.103 ms | AS2914 NTT 骨干 |
| 14 | 129.250.3.243 |
157.762 ms(asymm 15) | AS2914 NTT 骨干 |
| 18 | 192.220.2.210 |
157.982 ms | reached |
第 1–7、9 跳也有回应(11.247.233.54、11.73.130.158、10.92.111.226、10.216.218.138、10.216.229.102、106.38.196.225、36.110.245.209、202.97.84.214),为探测源内网与城域段;第 8/15/16/17 跳 no reply。 洛杉矶本地探测源一侧的回程同样落在 129.250.3.x。
4.3 路由看经过谁,ping 看有多快
这两件事不可互相替代:路由(tracepath)回答「数据包走了哪条路」,端到端 ping 回答「这条路走完要多久」。而且跳 RTT 不等于端到端延迟——广东侧第 11 跳是 160.364 ms、第 12 跳反而降到 152.883 ms,这种孤立大值是出口设备对 ICMP 做限速或排队的常见表现,不是真实路径延迟。洛杉矶侧第 9 跳在同一跳内同时出现 2.724 ms 与 106.925 ms 两个值,也是同一类现象。判断快慢以端到端 ping 为准。
由此能确定的只有一句:两个国内源的回程都落在 129.250.x.x(AS2914 NTT 骨干)上,属经 NTT 骨干的回程。 逐跳证据里没有出现 CN2 / 9929 / CMIN2 的段位,本文也不会这么写。至于 165 ms 这个量级:本次只测了 LAX-CUPN 这一条线路,没有对照组,只能说它与洛杉矶到华南的物理距离相符,不能说它是「最优」或「最快」。
还有一层边界要讲:本文只有广东电信与阿里云北京两个源,这两源覆盖不了全国。 联通、移动用户走哪条出口、落在哪个段,我们没有数据,因此全文只写「广东电信 + 阿里云北京双源」,不做全国口径的表述。如果你恰好是联通或移动用户,最可靠的办法是拿 192.220.2.210 这个 IP 在你自己的网络里 ping 一轮、tracepath 一轮——两个命令的输出格式和本文第四节完全一致,可以直接对照。
如果你还在洛杉矶和其他机房之间犹豫,美国 VPS 机房怎么选 那篇讲的是选址逻辑,可以和本文的实测对照着看。
五、带宽:119 Mbps 是「这次测到的」
| 项目 | 实测 |
|---|---|
Cachefly http://cachefly.cachefly.net/100mb.test |
speed_download=14932162 B/s、time_total=7.022265 s、size_download=104857600 |
| 换算 | 14.93 MB/s ≈ 119 Mbps(完整下载 104857600 字节) |
Cloudflare speed.cloudflare.com/__down?bytes=100000000 |
本次只返回 1 字节(异常) |
| 商家标称峰值 | 100–200 Mbps |
因为 Cloudflare 那个源这次没返回有效数据,所以本次带宽只有 Cachefly 一个源、一次、单线程。结论只能写到这个程度:14.93 MB/s ≈ 119 Mbps 落在商家标称的 100–200 Mbps 区间内。它既不是峰值上限的证明,也不代表任何时刻都能达到这个数字——单源单次单线程,测的是「这一次」。
对一台美国住宅IP VPS 来说,这个量级能支撑的是日常远程操作、轻量同步与中小文件分发这类用途。如果你要做大流量分发或长时间高带宽占用,请用多源、多时段的方式自己再测一轮,别拿本文这一次的结果当容量规划依据——单源单次单线程测不出上限,也测不出稳定性。
六、原生出口与流媒体:能说什么,不能说什么
开头那位做 TikTok 的朋友,后来又遇到过另一种情况:他换了 ISP 段的机器,出口查出来干干净净,账号还是被判了一次异常。他很困惑——段位不是升级了吗?这里缺的是一层认知:出口段位只是平台风控的一个输入,不是唯一输入。 登录环境、设备指纹、行为轨迹、账号历史都会参与判定。所以这一节我们把「出口是什么」和「服务能不能用」严格分开写,前者能测,后者测不了。
6.1 原生出口怎么验
对 cloudflare.com、chatgpt.com、api.openai.com 三处 cdn-cgi/trace 取的 ip、loc、colo 三个字段完全一致(warp 字段只在 cloudflare.com 那一处取到):
| 字段 | 值 |
|---|---|
ip |
192.220.2.210(与本机 IP 一致) |
loc |
US |
colo |
LAX |
warp |
off(仅 cloudflare.com 一处取到该字段) |
三处返回的 ip 都是本机 IP 192.220.2.210、colo 都是 LAX,cloudflare.com 那处额外返回 warp=off,说明出口即本机、没有走 WARP、没有中转。这也是「美国原生住宅IP VPS」这个说法里「原生」二字的实际含义:出口 IP 就是分配给你的那个 IP,中间没有套一层别人的代理或隧道。
但这只证明「原生出口」,不证明任何服务可用。 出口 IP 干净和平台让不让你用,是两件事,loc=US 不等于「解锁」。
6.2 页面可达性:200 与 401 各是什么意思
| 目标 | 状态码 | 说明 |
|---|---|---|
Netflix 美区片名页 /title/81215567 |
200(3,158,922 字节) | 正文未出现地区不可用提示 |
| Disney+ / Prime Video / DAZN / TikTok | 均 200 | 首页可达 |
api.openai.com/v1/models |
401 | 未带凭证 → 可达,非地区拒绝 |
401 是「没带凭证」,语义上属于接口可达;如果是地区拒绝,返回的通常不是 401。这一条只能写到「可达」,不能写成任何形式的可用承诺。
6.3 403 不等于封锁
Hulu 与 max.com 本次返回 403。但 curl 没有浏览器指纹、不执行 JS、不带 Cookie,而这两家都部署了成熟的 bot 防护——403 更可能是反爬拦截,本次未能判定它是否属于地区封锁。所以我们不写「不支持」或「被封锁」,只写「本次 403,未能判定」。
6.4 这次没测到什么
- 未做实际播放:Netflix 只验了一个片名页的 HTTP 状态码与体积,没有真实播放、没有登录账号。
- 未验证片库范围:单个片名页 200 不代表美区全片库可用。
- 未取到 YouTube
countryCode:两次抓取返回均为空,记为未取得。 - 状态码只代表页面可达性,不等价于服务可用、不等价于账号风控结论。
七、这次作废了哪些数据
把作废的东西写出来,比多报几个漂亮数字有用:
| 数据 | 为什么作废 |
|---|---|
ping www.nytimes.com → 151.101.193.164(nytimes.map.fastly.net);www.mit.edu → 23.51.196.111(e9566.dscb.akamaiedge.net) |
全部前置 CDN,测到的是最近的边缘节点而不是目标城市;由此得到的纽约 0.508 ms、多伦多 0.586 ms 物理上不可能,整组作废 |
speedtest-cli 2.1.4b1 --list |
只返回 10 个堪萨斯 / 俄克拉荷马节点,grep 洛杉矶 / 纽约 / 西雅图全部为空,样本残缺,作废 |
8.8.8.8 0.581 ms / 8.8.4.4 0.631 ms / 1.1.1.1 1.277 ms |
anycast 会命中本地节点,这是本地连通性,不是城市间延迟,本文不采用 |
一个通用提醒:拿域名去 ping 测北美城市间延迟,测到的几乎总是 CDN 边缘。 要测就得测 IP,并且确认那个 IP 不是 anycast;同理,speedtest-cli 的节点列表要完整才有意义,只返回 10 个中西部节点的列表,测出来的数字再漂亮也不能代表「美国速度」。
作废它们不影响本文的结论:本文的延迟只用三个探测源对同一台机器直连 ping 的结果,带宽只用 Cachefly 这一个明确的目标文件,两组数据都能复现。
八、适合谁,不适合谁
适合:
- 买美国住宅IP VPS 就是为了要美国 ISP 段出口的人。这类段位不会像机房段那样被直接打上数据中心标签——本机的 proxycheck 判定 risk 0、proxy=no 就是其中一例,但具体策略由各平台自行决定。
- 看重原生出口自建、不想走 WARP 或中转的人(三处 trace 已验证出口即本机)。
- 能接受 160–170 ms 国内往返延迟的轻量用途:探针、轻量 Web、自建中转、低并发采集。洛杉矶本地探测源 1.138 ms 的平均延迟,也适合面向美西用户的业务。
不适合:
- 想要 Cox / Comcast 那类消费者家宽段的人。本机是 NTT 的 ISP 段,按商家 FAQ 属「住宅IP」档,不是家宽档。
- 目标是 9929 / CN2 这类优化线路的人。逐跳证据显示它走的是 NTT 骨干。
- 要大内存、大磁盘的人:956 MB 内存(+ 1G swap)、可用 8.6G 磁盘。
- 要开箱编译环境的人:无
gcc/make/git,需自行 apt 安装。 - 想看联通 / 移动表现的人:本次只有广东电信与阿里云北京两个源,没有第三家运营商的数据。
上面这些判断全部来自本次实测到的资源边界,不掺推测。如果你更关心的是另一家同类产品怎么分组、实名与退款规则怎么写,AaITR 住宅 VPS 的产品线与规则 那一篇是同一主题的另一半,本文不重复。
九、常见问题
NovixLink 的住宅IP 是家宽吗?
不是。本机 IP 192.220.2.210 五源一致判为 AS2914 NTT America,ARIN 把 192.220.0.0/16 直接登记给 NTT America,NTT 官方 geofeed 标注 US-CA-Los Angeles。按 NovixLink 官网 FAQ 的定义,「住宅IP」来自 NTT / GTT / Cogent 这类 Tier-1 传输商,「家宽 IP」才是 Cox 等本土家庭宽带 —— 本机属前者。
国内访问延迟多少?
广东电信 AS4816 20 包:164.246/165.122/167.161/0.645 ms,0% 丢包;阿里云北京 AS37963 20 包:160.952/169.107/315.491/33.590 ms,0% 丢包。北京的 mdev 由第 2 包一个 315.491 ms 尖峰造成,其余 19 包在 160–163 ms。这是单时段快照,本文没有晚高峰与联通 / 移动数据。
带宽实测多少?是不是就是标称上限?
本次 Cachefly 单源单次单线程实测 14.93 MB/s ≈ 119 Mbps,落在商家标称 100–200 Mbps 区间内。Cloudflare 测速源本次只返回 1 字节未采用,因此没有第二个源可对照,这个数字不代表峰值上限。
能看 Netflix 吗?
本次只验证到美区单个片名页 /title/81215567 返回 200、3,158,922 字节、正文无地区不可用提示。未做实际播放、未登录账号、未验证片库范围,所以本文只报「页面可达」。
价格与活动在哪看?
本文不写价格与优惠码。这条线当前的价目与活动在 NovixLink 这条线的当前价目,另有 优惠码汇总页 可对照其他商家。
和其他美国住宅IP 产品怎么选?
同类型另一家的产品线、实名与退款规则写在 AaITR 美国静态住宅 VPS;同为洛杉矶 NTT 双 ISP 的另一家实测在 IPRaft 洛杉矶 NTT 双 ISP。本文只测 LAX-CUPN 一条线路,不做跨商家横评。
十、小结
这台机器能确定的事实是:KVM 真虚拟化 + 1 核 EPYC 7K62 + 956 MB 内存,磁盘顺序写 296 MB/s,本次下行 119 Mbps,广东电信与阿里云北京两源 20 包零丢包、平均 165.122 ms 与 169.107 ms,回程落在 NTT 骨干上,出口即本机无中转。 而它最有价值的地方,是把「住宅IP」这个词解释清楚了:它是 NTT 这样的 Tier-1 运营商段,不是 Cox 那样的消费者家宽。
搞清楚这一点,比多对比几个数字重要——你花钱买的到底是段位属性,还是某户人家的宽带,决定了它在你的业务里能不能达到预期。如果你的诉求是先拉一份候选名单,住宅IP VPS 推荐类的聚合文章更合适;本文只负责把这一台的每个数字讲透,不做跨商家横评。
想横向看更多真机记录,往期 VPS 实测汇总 与 主机商总览页 都在;同地区还有 洛杉矶机房怎么选 与 IPRaft 洛杉矶 NTT 线路实测 两篇可以对照。无论看哪一篇,都建议先照本文第三节的方法查一次 ASN——挑洛杉矶住宅IP VPS,查清段位归属比比对参数更重要。
数据说明:本文所有数据来自商家提供的同一台真机(LAX-CUPN,IP 192.220.2.210)与三个只读探测源 —— 中国广东·电信 AS4816(单线)、中国北京·阿里云 BGP AS37963、美国洛杉矶·AS402506 —— 于同一时段实跑,命令与原始输出原样引用,未做取整或改写。真机内数据含 dd 双组、Python 微基准、Cachefly 下载、cdn-cgi/trace 与流媒体 HTTP 状态码;探测源数据含 ping -c 20 完整统计与 tracepath -n -m 30 逐跳。未跑 UnixBench 与 fio,故无跑分与 IOPS;无多时段采样,故无晚高峰结论;国内仅双源,不代表全国;无 IPv6 数据;流媒体仅验 HTTP 状态码,未做实际播放与片库验证;本文不写价格与优惠码,也不对任何平台的风控结果作承诺。商家「住宅IP / 家宽 IP」定义引自 NovixLink 官网 FAQ。
