美国住宅IP VPS测评：NovixLink 洛杉矶 NTT 真机跑分与多时段实测

买美国住宅IP VPS的人，最后多半卡在同一个地方：商家嘴里的「住宅IP」，到底是不是你脑子里那个「住宅」。 一位做 TikTok 的朋友纠结了半个月：账号总被判成数据中心流量，他问换住宅IP 是不是就一劳永逸；另一位读者更郁闷，下单时买的是「美国家庭宽带」，到手一查 IP 归属，落在运营商自己的段上，跟 Cox、Comcast 那种真正的家庭宽带根本不是一回事。

这次我们不打嘴仗，直接用一台真机把这件事测出来。NovixLink（诺联主机）LAX-CUPN 线路提供了一台测试机，IP 为 192.220.2.210。本文所有数据都来自这一台机器：真机内的 UnixBench 跑分、fio 磁盘矩阵、多源带宽与出口探测，加上中国大陆两个只读探测源与美国洛杉矶一个探测源对它的 ping 与 tracepath。

先给结论：这是一台 KVM 真虚拟化、1 核 AMD EPYC 7K62、956 MB 内存的机器；UnixBench 5.1.3 单核 Index Score 为 1260.3；fio 的 4K 随机读在队列深度 1 到 128 之间都停在约 2500 IOPS（≈9.77 MB/s），延迟严格按队列深度线性放大，说明后端随机 IO 是串行的；四个独立测速源的下行稳定落在 119 / 114 / 108 / 97 Mbps 量级，跨源一致，指向端口限速而不是测速源偏慢。而它的 IP 经 IPlense 专业模式所聚合的 9 家数据源横向对比，可用 5 家全部指向 AS2914 NTT America 的 ISP 段——按 NovixLink 官网 FAQ 的定义，它属于「住宅IP」档，不是消费者家宽 IP。

这次没测到什么，也一并写在前面：国内只有广东电信与阿里云北京两个源，没有联通与移动，所以全文只写「双源」；无 IPv6 数据；流媒体只验到 HTTP 状态码，未做实际播放；IPlense 专业模式聚合的 9 家数据源里有 4 家需要私有 API key，本次未申请，因此只取到 5 家；本文不写价格与优惠码。

一、这台机器是什么：先把身份钉死

真正值得单独说的是工具链。实测 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 当成价值本身读（它到底属于谁的段）。本文后面几节就是按这个顺序展开的。

二、跑分：UnixBench 与 fio

2.1 UnixBench 5.1.3：单核 Index Score 1260.3

跑分用 byte-unixbench 5.1.3（与本站往期实测同一版本，便于纵向对照）。1 核机器只跑 -c 1，并且是清场后单实例空载重跑：先杀净全部残留进程、确认只剩一个实例，再启动。

benchmark run 窗口为 Sat Oct 03 2026 12:26:41 - 12:33:24（UTC），起始 load average 0.16 0.88 0.86——这个基线说明跑分开始时机器上确实没有别的重负载。

怎么读这组数：Index = 实测结果 ÷ 基线 × 10，Index Score 是 12 项 Index 的几何平均。 12 项里最高的三项是 File Copy 4096（4468.1）、Dhrystone 2（3696.2）、File Copy 1024（2688.8），最低的是 Pipe-based Context Switching（572.8）、Execl Throughput（573.8）、Shell Scripts 8 并发（574.0）。这个形状是单核轻量实例的典型分布：内存内计算与页缓存拷贝得分高，涉及进程创建、上下文切换与并发调度的项目得分低——因为只有 1 个核，8 并发脚本要在一个核上轮流跑。

一句边界：UnixBench 分数随虚拟化平台与同宿主机邻居负载波动，不宜跨平台直接横比。 本文给的是这一台在这一次的分数，不据此下「性能强 / 弱」的结论。

2.2 fio：4K 随机 IOPS 与队列深度扫描

磁盘用 fio 3.41 跑标准矩阵：1G 测试文件，libaio + direct=1 + numjobs=1 + time_based，QD1/QD32 跑 60 秒、QD64/QD128 跑 30 秒，ramp_time=5。延迟一栏取 clat（设备完成延迟），不是含提交开销的 lat。

这张表里最有信息量的是前四行。把队列深度从 1 一路加到 128：

• IOPS 几乎不动：2499.975 → 2499.550 → 2497.935 → 2495.890，全程波动不到 0.2%；
• clat 均值却严格按队列深度线性放大：385.913 → 12790.804 → 25599.016 → 51230.047 µs，QD128 相对 QD1 是 132.7 倍。

队列深度翻 128 倍、IOPS 一动不动、延迟按倍数等比放大——这是「后端每次只处理一个 IO」的典型特征。 用 QD1 的 385.913 µs 反推，单次 4K 随机 IO 的服务时间约 0.39 ms，上限就是 1 ÷ 0.000385913 ≈ 2591 IOPS 量级，实测稳定在 2500 附近。也就是说，这台机器的 4K 随机能力上限约 2500 IOPS，折合 9.77 MB/s；加深队列只会让每个请求等更久，不会让总吞吐变高。

两个附带现象同样值得记：

• 混合负载里写比读快得多：70%读/30%写同时跑时，读的 clat 均值 12681.176 µs，写的 clat 均值只有 246.281 µs，差约 51 倍。写请求被前端的写缓存吸收后即可返回，读请求则必须落到后端那条约 0.39 ms 的串行通道上排队。
• 瓶颈在 IOPS，不在带宽：1M 顺序读能到 299.996 MB/s、顺序写 295.233 MB/s，是 4K 随机读带宽（9.766 MB/s）的 30 倍以上。同一块盘，顺序能到 300 MB/s 量级、随机只有 9.766 MB/s，说明限的是每秒 IO 次数而不是通道宽度。

2.3 dd 与 CPU 微基准

dd 那两组数和 fio 是同一个盘的三种测法，放在一起正好互相校验：296 MB/s 是 1M 块直接写，352 MB/s 是 4k 块带 conv=fdatasync 的刷盘吞吐，而 fio 的 1M 顺序写给出 295.233 MB/s。三者都在 300 MB/s 量级，互相不矛盾。

conv=fdatasync 那一项常被误读成「4K 随机 IOPS」，它其实衡量的是顺序写的落盘能力——真要 4K 随机 IOPS，看的是上一节的 fio 表格。

2.4 怎么读这组数字

三点提醒：

第一，不同工具测的是不同的东西。UnixBench 测的是 CPU 与系统调用的综合响应，fio 测的是块设备的 IO 能力，dd 测的是顺序吞吐。它们互相不能换算——1260.3 这个分数不能推出 IOPS，2500 IOPS 也不能推出 CPU 强弱。

第二，UnixBench 是 1 核单实例，fio 是单 job，两者都没有并发压力。真实业务里同时跑 CPU 与磁盘负载时，1 核会被抢，实测值会低于这里的单打独斗。

第三，顺序与随机的差距（30 倍）比绝对数值更重要。这台机器的磁盘顺序读写接近 300 MB/s，但 4K 随机只有 9.77 MB/s、2500 IOPS。如果你要跑数据库、大量小文件读写、容器镜像层解压这类随机 IO 密集的场景，决定体验的是 2500 IOPS 这个数，不是 300 MB/s 那个数。

三、「住宅IP」到底是什么：用 192.220.2.210 反推

这一节是本篇最重要的部分，也是中文圈几乎没人正面回答过的问题：住宅IP 和家宽 IP 到底是不是一回事。

先讲那位读者的经历。他买的时候商品页写「美国家宽」，拿到机器去查，IP 落在一家 Tier-1 运营商的段上。他去问客服，客服说「这就是我们的住宅IP」。双方说的其实都没错，错的是两个中文词被混用了。

NovixLink 的用户条款里写明：IP 判断标准以 IPlense.cc 为准，并建议用该站的专业模式取多源数据对比。 下面这一节就照这个标准来做。

3.1 IPlense 专业模式：9 家数据源横向对比

IPlense 的 Professional Check 并不自己下判断，而是把 9 家第三方 IP 数据源的结论并排展示，让你看分歧。这 9 家是：IPLocate、IPAPI（ipapi.is）、IPData（ipdata.co）、Abstract API、Ipregistry、IPGeolocation.io、IPInfo、ProxyCheck v3、AbuseIPDB。

需要说明取数方式：IPlense 的查询接口挂在 Cloudflare Turnstile 人机验证后面，自动化访问无法通过验证，所以这里直接调用这 9 家数据源各自的官方公开接口取同一批数据，而不是抄 IPlense 页面上的一张截图。9 家里有 5 家提供无需注册的公开端点，另外 4 家（IPData、IPGeolocation.io、Abstract API、AbuseIPDB）返回 401、需要私有 API key，本次未申请，因此下表是 5 家而不是 9 家。

5 家全部指向 AS2914 NTT America、位置全部指向洛杉矶。 这是本节要的结论。

但多源对比的价值不只是「大家都说 A」。这张表里同时有三处不一致，而它们恰恰是最容易被忽略、也最容易被拿来做文章的地方：

1. IPLocate 同时给出 type="isp" 和 is_hosting=true。 前者是地址段类型，后者是「是否属于托管/机房环境」的标记，两者并不冲突，但只看其中一个就会得出相反印象——只看到 is_hosting=true 的人会说「这不是住宅IP」，只看到 type="isp" 的人会说「这就是 ISP 段」。
2. ProxyCheck 给的是 type="Business"，不是 residential 也不是 hosting。 这是它自己的用途分类口径，与 IPLocate 的 type="isp"、Ipregistry 的 type="isp" 不在同一个维度上，不能反过来读成「其实不是住宅IP」——反向夸大同样是夸大。
3. 连段范围和邮编都没对齐：段范围 IPLocate 与 Ipregistry 写 192.220.0.0/16、ProxyCheck 写 192.220.2.0/17；邮编出现 90001、90009、90013 三个值。

这三点说明的是同一件事：IP 数据源之间本来就没有统一口径。 所以「多源对比」的正确用法不是投票选多数，而是先分清每个字段属于哪个维度，再决定哪个维度对你的用途有约束力。

3.2 五源一致判 AS2914

上表 5 家加上本次单源复核，结论收敛在一点：

3.3 第二、三级：ARIN 登记与 NTT 官方 geofeed

商业库只是第三方判断，往上还有两级硬证据：

• ARIN 把 192.220.0.0/16 登记为 Direct Allocation 给 NTT America。 这是地址段的注册归属，不是任何第三方库的推测。IPLocate 返回的 rir 字段同样标注为 ARIN。
• NTT 官方 geofeed 把该段标注为 US-CA-Los Angeles。 这是运营商自己发布的地理位置数据。

三级证据（商业库 → 注册机构 → 运营商自述）在同一结论上闭合：这个 IP 属于 NTT America 在洛杉矶的 ISP 段，且不是代理出口（proxy=no、risk=0、is_anycast=false）。

3.4 商家 FAQ 自己怎么定义

NovixLink 官网 FAQ 的表述是：其「住宅IP」来自 NTT / GTT / Cogent 这类 Tier-1 传输商；而「家宽 IP」才是 Cox 等本土家庭宽带。也就是说，在商家的产品语言里，「住宅IP」指的是运营商段位的属性，「家宽 IP」指的是消费者家庭宽带线路。

3.5 结论：本机是「住宅IP」档，不是消费者家宽 IP

把两件事拼起来就闭合了：本机 IP 是 AS2914 NTT America 的 ISP 段（5 家数据源 + ARIN + geofeed），而商家 FAQ 明确「住宅IP 来自 NTT / GTT / Cogent」→ 本机落在商家定义的「住宅IP」档内；同时商家 FAQ 明确「家宽 IP 才是 Cox 等本土家庭宽带」→ 本机不是消费者家宽 IP。

这就是本文标题里「美国住宅IP VPS测评」要回答的核心：你买到的「住宅」，是运营商段位的住宅，不是某户人家客厅里的那根宽带。

3.6 中文圈为什么会混淆

原因在英文词：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 分时段采样

口径先说清：cn-* 是「国内探测源访问这台机器」的延迟，us-* 是「美国本地探测源访问这台机器」的延迟，两者不是同一件事，不可混写。

单时段给一个数字没有意义，因为国际线路的延迟和丢包在一天里是变化的。这次的做法是：同一台机器、同一组探测源、同一套命令（ping -c 20），在不同时段各跑一轮，把时间序列并排看。目前已采集 5 轮，覆盖 3 个时段：高峰、平峰、低谷（其中低谷、平峰在隔日复测一次，用来核对同一时段的数字能不能复现）。

把 高峰 与 低谷 两轮并排：广东电信从 158.679 ms 变成 158.036 ms（差 -0.643 ms），阿里云北京从 155.359 ms 变成 155.192 ms（差 -0.167 ms）。每轮都标注具体时刻，不做跨时段平均，因为平均会把时段差异抹掉。

低谷这一轮里，广东电信与阿里云北京两源平均延迟相差 2.844 ms（158.036 ms vs 155.192 ms），两源各 20 包均为 0% 丢包；洛杉矶本地源 1.209 ms 说明机器确实在洛杉矶本地网络内。同一轮里两个国内源的差值本身比绝对数字更值得看——它说明两家出口路径不完全一样，而不是某一家的线路「更差」。

4.2 单次 20 包完整统计

广东电信 AS4816 的 0.645 ms mdev 说明这批包非常集中。北京阿里云 AS37963 的 mdev 是 33.590 ms，但这个数字是被第 2 包一个 315.491 ms 的尖峰单独拉高的，其余 19 包都在 160–163 ms 之间——所以这里不能写成「抖动大 / 不稳定」，原样给出统计并说明成因才是对的。

三个源里，洛杉矶本地的 1.138 ms 平均值与 ipinfo 的 postal 90013、NTT geofeed 的 US-CA-Los Angeles 相互印证——选美国住宅IP VPS 时，这条「地理位置三重印证」比任何一个延迟数字都更有参考价值，因为它告诉你的不是快不快，而是它在不在你说的地方。

4.3 路由逐跳：看它经过谁

下表的「归属」一栏全部来自对每一跳 IP 逐个做的 ipinfo 查询（骨干网 IP 的地理标注不可信，因此只标 ASN，不标城市）。

广东侧（tracepath -n -m 30，19 跳，pmtu 1500），只列有回应的关键跳：

第 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）：

第 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.4 路由看经过谁，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 的段位，本文也不会这么写。至于 155–165 ms 这个量级：本次只测了 LAX-CUPN 这一条线路，没有对照组，只能说它与洛杉矶到华南的物理距离相符，不能说它是「最优」或「最快」。

还有一层边界要讲：本文只有广东电信与阿里云北京两个源，这两源覆盖不了全国。 联通、移动用户走哪条出口、落在哪个段，我们没有数据，因此全文只写「广东电信 + 阿里云北京双源」，不做全国口径的表述。如果你恰好是联通或移动用户，最可靠的办法是拿 192.220.2.210 这个 IP 在你自己的网络里 ping 一轮、tracepath 一轮——两个命令的输出格式和本文第四节完全一致，可以直接对照。

如果你还在洛杉矶和其他机房之间犹豫，美国 VPS 机房怎么选 那篇讲的是选址逻辑，可以和本文的实测对照着看。

五、带宽：四源多轮，119 Mbps 是端口上限

测带宽最容易犯的错是「只跑一个源、一次、单线程」。这次在测试机内用 curl 强制 IPv4，对 4 个互相独立的公开测速文件各跑 3 轮，每轮上限 30 秒，全部完整下载。下表是晚间高峰 21:35 那一轮；各时段的跨时段对照见第四节的多时段卡。

三个关键读法：

第一，同一源的 3 轮几乎完全一致。 Cachefly 三轮分别是 119.456 / 119.398 / 119.383 Mbps，极差只有 0.073 Mbps。这种复现性说明测的不是随机波动，而是被某个稳定的东西卡住了。

第二，跨源一致指向同一个量级。 四个源分处美西、美中、美东、日本，路径完全不同，却都落在 97–119 Mbps 的窄带里。如果瓶颈在「某个测速源太慢」，四个不同源的路径不会这么整齐。跨源一致 + 单源内极低波动 = 限速点在本地出口，不在对端。

第三，最高值 119.412 Mbps 与商家标称的 100–200 Mbps 区间吻合，落在区间下沿。 按 4K 随机读 9.766 MB/s、1M 顺序读 299.996 MB/s 的表现看，磁盘不是瓶颈；四个源也排除了对端因素。因此本文能说的是：这台机器这次测到的下行上限在 119 Mbps 附近，跨源复现良好。 至于它是商家配置的 100 Mbps 端口还是更高带宽上的限速策略，本文没有控制台数据，不做判定。

对一台美国住宅IP VPS 来说，119 Mbps 这个量级能支撑的是日常远程操作、轻量同步与中小文件分发。如果你要做大流量分发或长时间高带宽占用，请用同样的多源多轮方式自己再测一轮，别拿本文一次的结果当容量规划依据。

六、原生出口与流媒体：能说什么，不能说什么

开头那位做 TikTok 的朋友，后来又遇到过另一种情况：他换了 ISP 段的机器，出口查出来干干净净，账号还是被判了一次异常。他很困惑——段位不是升级了吗？这里缺的是一层认知：出口段位只是平台风控的一个输入，不是唯一输入。 登录环境、设备指纹、行为轨迹、账号历史都会参与判定。所以这一节我们把「出口是什么」和「服务能不能用」严格分开写，前者能测，后者测不了。

6.1 原生出口怎么验

对 cloudflare.com、chatgpt.com、api.openai.com 三处 cdn-cgi/trace 取的 ip、loc、colo 三个字段完全一致（warp 字段只在 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 各是什么意思

401 是「没带凭证」，语义上属于接口可达；如果是地区拒绝，返回的通常不是 401。这一条只能写到「可达」，不能写成任何形式的可用承诺。

6.3 403 不等于封锁

Hulu 与 max.com 本次返回 403。但 curl 没有浏览器指纹、不执行 JS、不带 Cookie，而这两家都部署了成熟的 bot 防护——403 更可能是反爬拦截，本次未能判定它是否属于地区封锁。所以我们不写「不支持」或「被封锁」，只写「本次 403，未能判定」。

6.4 这次没测到什么

• 未做实际播放：Netflix 只验了一个片名页的 HTTP 状态码与体积，没有真实播放、没有登录账号。
• 未验证片库范围：单个片名页 200 不代表美区全片库可用。
• 未取到 YouTube countryCode：两次抓取返回均为空，记为未取得。
• 状态码只代表页面可达性，不等价于服务可用、不等价于账号风控结论。

七、这次作废了哪些数据

把作废的东西写出来，比多报几个漂亮数字有用：

最后三行是测速源筛选留下的记录：正式采样前先对候选源做了一轮可达性与速度筛查，把解析失败、端口被拒、被 403、收不到字节的源全部剔除，只保留 4 个能完整下载的源。如果直接把不合格的源混进结果，它们的「0 Mbps」会被误读成「带宽很差」，那才是真正的错误。

两个通用提醒：拿域名去 ping 测北美城市间延迟，测到的几乎总是 CDN 边缘——要测就得测 IP，并且确认那个 IP 不是 anycast；同理，测速源要先筛后用，一个连不上的源和一个很慢的源在数字上可能都是 0，含义完全不同。

作废它们不影响本文的结论：本文的延迟只用三个探测源对同一台机器直连 ping 的结果，带宽只用 4 个经过筛查、能完整下载的公开测速文件，两组数据都能复现。

八、适合谁，不适合谁

适合：

• 买美国住宅IP VPS 就是为了要美国 ISP 段出口的人。这类段位不会像机房段那样被直接打上数据中心标签——本机的 proxycheck 判定 risk=0、proxy=no、Ipregistry 的 security 字段全为 false 就是其中一例，但具体策略由各平台自行决定。
• 看重原生出口自建、不想走 WARP 或中转的人（三处 trace 已验证出口即本机）。
• 能接受 155–165 ms 国内往返延迟的轻量用途：探针、轻量 Web、自建中转、低并发采集。洛杉矶本地探测源 1.138 ms 的平均延迟，也适合面向美西用户的业务。
• 用途以顺序读写为主的人：1M 顺序读写接近 300 MB/s，跑得动文件分发与流式写入。

不适合：

• 想要 Cox / Comcast 那类消费者家宽段的人。本机是 NTT 的 ISP 段，按商家 FAQ 属「住宅IP」档，不是家宽档。
• 随机 IO 密集的场景：4K 随机读写只有约 2500 IOPS（≈9.77 MB/s），且加深队列深度无效——数据库、大量小文件、容器镜像层解压这类负载会卡在这里。
• 目标是 9929 / CN2 这类优化线路的人。逐跳证据显示它走的是 NTT 骨干。
• 要大内存、大磁盘的人：956 MB 内存（+ 1G swap）、可用 8.6G 磁盘。
• 要开箱编译环境的人：无 gcc / make / git，需自行 apt 安装。
• 想看联通 / 移动表现的人：本次只有广东电信与阿里云北京两个源，没有第三家运营商的数据。

上面这些判断全部来自本次实测到的资源边界，不掺推测。如果你更关心的是另一家同类产品怎么分组、实名与退款规则怎么写，AaITR 住宅 VPS 的产品线与规则 那一篇是同一主题的另一半，本文不重复。

九、常见问题

NovixLink 的住宅IP 是家宽吗？

不是。本机 IP 192.220.2.210 经 IPlense 专业模式所聚合的数据源横向对比，可取的 5 家（IPLocate、IPAPI、IPInfo、ProxyCheck v3、Ipregistry）全部指向 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 等本土家庭宽带 —— 本机属前者。

UnixBench 跑分多少？

UnixBench 5.1.3、1 核单实例空载，System Benchmarks Index Score = 1260.3。12 项里最高的是 File Copy 4096（Index 4468.1）、Dhrystone 2（3696.2）、File Copy 1024（2688.8），最低的是 Pipe-based Context Switching（572.8）、Execl Throughput（573.8）、Shell Scripts 8 并发（574.0）。只有 1 核，8 并发脚本要在一个核上轮流跑，所以并发类项目分数偏低。

磁盘 IOPS 是多少？

fio 3.41，1G 文件、libaio + direct=1 + 单 job：4K 随机读 QD1 为 2499.975 IOPS、QD32 为 2499.550 IOPS、QD64 为 2497.935 IOPS、QD128 为 2495.890 IOPS。队列深度从 1 加到 128，IOPS 几乎不变，而 clat 均值从 385.913 µs 线性放大到 51230.047 µs——说明后端随机 IO 是串行的，上限约 2500 IOPS（≈9.77 MB/s）。1M 顺序读 299.996 MB/s、写 295.233 MB/s，瓶颈在 IOPS 而非带宽。

国内访问延迟多少？

广东电信 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。晚间高峰 21:35 那一轮，两源平均分别为 158.679 ms 与 155.359 ms，同样 0% 丢包。本文没有联通 / 移动数据。

带宽实测多少？是不是就是标称上限？

4 个独立测速源各跑 3 轮、全部完整下载：三个美国源跨时段稳定（Cachefly 119.333–119.460 Mbps、Linode Dallas 114.488–114.622 Mbps、Linode Newark 108.490–109.860 Mbps），东京源 86.897–100.233 Mbps 波动较大。跨源一致 + 单源低波动指向本地端口限速，而不是测速源偏慢；最高 119.460 Mbps 落在商家标称 100–200 Mbps 的下沿。本文没有控制台数据，不判定它是 100 Mbps 端口还是更高带宽上的限速策略。

能看 Netflix 吗？

本次只验证到美区单个片名页 /title/81215567 返回 200、3,158,922 字节、正文无地区不可用提示。未做实际播放、未登录账号、未验证片库范围，所以本文只报「页面可达」。

价格与活动在哪看？

本文不写价格与优惠码。这条线当前的价目与活动在 NovixLink 这条线的当前价目，另有 优惠码汇总页 可对照其他商家。

和其他美国住宅IP 产品怎么选？

同类型另一家的产品线、实名与退款规则写在 AaITR 美国静态住宅 VPS；同为洛杉矶 NTT 双 ISP 的另一家实测在 IPRaft 洛杉矶 NTT 双 ISP。本文只测 LAX-CUPN 一条线路，不做跨商家横评。

十、小结

这台机器能确定的事实是：KVM 真虚拟化 + 1 核 EPYC 7K62 + 956 MB 内存；UnixBench 5.1.3 单核 Index Score 1260.3；fio 的 4K 随机读在 QD1 到 QD128 之间都停在约 2500 IOPS、延迟按队列深度线性放大，1M 顺序读写接近 300 MB/s；四个独立测速源的下行落在 86.897–119.460 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 —— 命令与原始输出原样引用，未做取整或改写。真机内数据含 UnixBench 5.1.3 单核跑分、fio 3.41 磁盘矩阵（QD1/32/64/128）、dd 双组、Python 微基准、四源多轮下行、cdn-cgi/trace 与流媒体 HTTP 状态码；探测源数据含 ping -c 20 完整统计与 tracepath -n -m 30 逐跳。多源 IP 归属数据取自 IPlense 专业模式所聚合的数据源各自的官方公开接口（IPLocate、IPAPI、IPInfo、ProxyCheck v3、Ipregistry 五家；IPData、IPGeolocation.io、Abstract API、AbuseIPDB 四家需私有 API key，本次未申请）。国内仅双源，不代表全国；无 IPv6 数据；流媒体仅验 HTTP 状态码，未做实际播放与片库验证；本文不写价格与优惠码，也不对任何平台的风控结果作承诺。商家「住宅IP / 家宽 IP」定义与 IPlense 判定标准引自 NovixLink 官网 与 IPlense。