四台 VPS：纸面身份和延迟不是一回事
我从同一条北京联通家宽测试四台自建 VPS，分别查看登记信息、地理库与风控标签，再测到节点的 RTT、访问目标站的延迟和 10MB 下载。这轮测量中大阪节点的延迟较低，Frontier 段的数据库标签更接近住宅地址；两类结果回答的问题不同。
数据库标签和网络表现分开看。
大阪节点在这轮延迟测试中表现较好，洛杉矶节点和 Frontier 段的下载速率接近。AT&T 段与 Frontier 段的登记、风控标签另见下表。本文没有做真实账号登录测试，不能保证某个号段通过目标站的风控。
纸面合格不等于目标站会把它当住宅。地理库过了，只说明 MaxMind 这类库暂时没把它判到别的国家。
四台机器，只保留类型
公开比较只保留线路类型，不写地址。四台都是自己控制的 VPS，协议相同，都走 Reality 这类 TLS 伪装，从同一台 Mac 测。
纸面身份
先问登记处和地理库，再问风控库。脚本输出一档判定：pass / caution / reject。这一档只描述「像不像美国住宅」，不描述「快不快」。
| Frontier 段 | AT&T 段 | 洛杉矶机房 | 大阪机房 | |
|---|---|---|---|---|
| 判定 | pass | pass | reject | reject |
| 登记库 | ARIN | ARIN | ARIN | RIPE，国家 JP |
| 三库国家 | 都是 US | 都是 US，城市在打 | 都是 US | 都是 JP |
| 是不是 ISP | 是，Verizon / Frontier | 是，AT&T | 不是 | 不是 |
| 风控 | Residential，risk 0 | Business，risk 0 | vpn，risk 66，机房 | vpn，risk 66，机房 |
| PTR | 运营商反向区 | 没有 | 机房品牌名 | 机器自己的主机名 |
| DNSBL | 未列入 | 未列入 | 未列入 | 未列入 |
本次脚本按登记信息和多家地理库的结果判断国家。ARIN 的 country 为空时，不能直接判定为非美国；大阪节点则有 RIPE 的 JP 登记与地理库结果。网络延迟是另一组测量，不用来替代这些字段。
AT&T 段的 RDAP 组织名是 Private Customer。这是北美登记处常见的隐私占位，不是租赁商。如果把「组织和 ASN 对不上」直接打成租赁，会误伤真宽带段。
洛杉矶节点曾被脚本标成 lease。回查 RDAP 原文才发现，正则匹配的是 Please 中的子串 lease。改成整词匹配后，这条假阳性消失；机房和 VPN 标签仍在，所以脚本最后的 reject 没变，但依据已经不同。
PTR 是反过来查名字
平常 DNS 是「名字到地址」。PTR 是「地址到名字」。别人拿到一个 IP，问系统这是谁的号，如果运营方配了反向记录，就会回一个主机名。
家宽常见的是运营商自己的反向区，比如 Frontier、Verizon、AT&T 那一套。机房常见的是公司名，或者机器自己的主机名。没有 PTR 也很常见，不能单独否决。
只认 hsd1 / dsl / cable 会漏掉 Frontier 这种静态反向区。看是不是运营商后缀，比看接入层主机名更稳。
到节点有多远
Ping 和 TCP 打的是入口，不是网站。AT&T 段的管理入口是中继，所以它会比出口再慢一截。
| Frontier 段 | 洛杉矶机房 | AT&T 中继 | 大阪机房 | |
|---|---|---|---|---|
| Ping 平均 | 177 ms | 177 ms | 236 ms | 120 ms |
| 丢包 | 0 | 0 | 0 | 本轮 8 次丢 1 |
| TCP 握手 | 197 ms | 178 ms | 210 ms | 140 ms |
大阪机从联通出来以后很快进日本段，到节点大约 115 ms。Frontier 段走的是联通 163 再接 Cogent，不是 CN2。洛杉矶机房国内段出现过常见的 CN2 特征地址，ICMP 不一定能打到主机，TCP 仍然通。
端到端延迟
这不是 ICMP。数字是本地内核经该节点做完握手，再访问目标站的时间。每个站两次，取平均。
| 目标 | Frontier 段 | 洛杉矶机房 | AT&T 段 | 大阪机房 |
|---|---|---|---|---|
| gstatic 204 | 178 | 170 | 238 | 116 |
| google.com | 168 | 186 | 224 | 158 |
| youtube.com | 472 | 447 | 478 | 266 |
| github.com | 223 | 178 | 287 | 131 |
| chatgpt.com | 786 | 794 | 897 | 576 |
| anthropic 连通 | 243 | 232 | 286 | 268 |
大阪节点在这轮多数目标站测试中耗时较低。ChatGPT 首页的 TTFB 在四条路径上都偏高，仅凭每站两次请求，无法确定慢在目标站、路由还是其他环节，也不宜据此推断长期稳定性。
能连上 anthropic 的 API 入口只说明端口通。四台都能通。过不过账号风控，要另测，这篇没有用真实登录去打。
下载
把出口切到该节点，拉 10MB。速度按 curl 的下载速率换算。
| Frontier 段 | 洛杉矶机房 | AT&T 段 | 大阪机房 | |
|---|---|---|---|---|
| Cachefly 10MB | 31.4 Mbps | 32.5 Mbps | 25.4 Mbps | 空响应 |
| Cloudflare 10MB | 29.1 Mbps | 28.8 Mbps | 22.2 Mbps | 14.9 Mbps |
两条美国路径的下载速率接近。大阪节点访问 Cachefly 时收到 HTTP 200，但内容是 0 字节；换 Cloudflare 后取得了下载结果。AT&T 段也完成了测试，不过单轮下载不能证明长期稳定。
怎么测，以及公开时删了什么
身份层：RDAP、ipinfo、ip-api、ipwho、proxycheck、ipapi.is、PTR、RIPEstat BGP。系统 DNS 在 TUN fake-ip 下不能做 DNSBL，改走国内 DoH。
网络层：入口 ping / TCP；内核延迟接口访问固定站点；再切出口拉 10MB。测完把默认出口改回去。
公开稿删除：所有 IP、含地址的反向解析、主机名、节点名、小商家面板名、端口、UUID 和登录方式。保留的是类型、ASN 归属类别、和这一轮测到的毫秒 / Mbps。
这些结果只对应本次线路、目标站和时段。更换本地运营商或测试时间后，绝对值与相对排序都可能变化，需要重新测量。