发布于 更新于
IP 查询是网络排查里成本最低的一步：一次请求，就能知道远端服务实际看到的是哪个地址。它也是被过度解读最严重的一步。结果描述的是某一时刻的网络出口，而不是某个人、某个家庭，很多时候连城市都算不上。本文讲清楚这些字段是怎么来的、每一项能信到什么程度，以及如何对比地址族和浏览器层面的信号，而不得出数据本身撑不住的结论。
IP 查询能告诉你什么
公网 IP 查询只回答一个很窄的问题：这次请求的源地址是什么，路由和注册数据对这个地址怎么说。由此你能读到地址族、宣告覆盖前缀的自治系统号、该前缀在区域互联网注册机构登记的所属组织，以及一个地理位置估计值。前三项是关于路由的事实，最后一项是推断。
地址本身是数据包这一次恰好走出去的那个出口。运营商级 NAT 把成千上万的用户放在同一个地址后面；企业网关把整个办公室放在同一个地址后面，而那个城市可能没有一个同事住在那里；移动网络还可能把设备从与其驻留小区完全不同的区域的网关送出去。把 IP 结果当成网络路径的属性，不要当成用户的属性。
粒度越细，可信度掉得越快。在你打算让程序依据查询结果做任何决定之前，先看这张表。
| 信息项 | 典型可信度 | 数据来源 | 合理用途 |
|---|---|---|---|
| 地址族与前缀 | 精确 | 数据包头与路由表 | 可以直接据此处理 |
| ASN 与登记运营商 | 很高 | BGP 宣告与 RIR 注册记录 | 区分数据中心、家宽与移动网络 |
| 国家 | 固网较高，移动、卫星与 anycast 较弱 | 注册分配加厂商测量 | 粗粒度路由、默认语言、区域内容策略 |
| 省 / 州 | 中等 | 厂商推断 | 只当线索，需另一来源佐证 |
| 城市 | 不稳定，常常是运营商的区域汇聚点 | 时延与采集推断 | 绝不能作为影响到具体个人的唯一依据 |
| 邮编或经纬度 | 低，经常是国家或区域的几何中心 | 插值与兜底默认值 | 仅供排查，不要作为用户所在地展示 |
| 街道地址或门牌 | 拿不到 | 数据里根本没有 | 任何声称能给出这一级的产品都是在猜 |
对比 IPv4 与 IPv6 的行为
在双栈网络里，单次查询给出的信息比你以为的少，因为地址族是浏览器替你选的。Happy Eyeballs（RFC 8305）会同时发起 IPv6 与 IPv4 连接并采用先完成的那条，且对 IPv6 有偏好。所以同一台没有任何改动的机器，上午看到的是 IPv6 地址、下午看到的是 IPv4 地址，原因可能仅仅是其中一条路径变慢了。
想拿到有用的答案，就要通过只发布 A 记录或只发布 AAAA 记录的主机名，分别询问每个地址族。本站的 IP Network Check 正是这样做的：浏览器直连一个纯 IPv4 探测入口和一个纯 IPv6 探测入口，因此「没有结果」本身就是结论。如果 IPv6 探测始终不返回，说明这条路径上确实没有 IPv6 —— 操作系统、路由器或者 ISP 没有提供 —— 而不是只是这次没被选中。
真正的诊断价值在于把两个结果并排看。家宽和移动网络的 IPv4 地址大多通过运营商级 NAT 共享，你看到的可能只是地址池里的一个，而且随时会变。IPv6 的行为不同：高位是 ISP 委派给你的前缀，相对稳定；接口标识部分在启用临时地址扩展（RFC 8981）时会按时间轮换。所以 IPv6 地址每天都在变是正常现象，值得追查的是它下面的前缀发生了变化。
- 白名单里只写了 203.0.113.47，那么每当 IPv6 赢得竞速，这台机器就会被拒绝 —— 这正是典型的「我这边是好的」间歇性故障。
- IPv6 要放行运营商委派的整个前缀（通常是 /56 或 /64），不要放行单个地址，因为低位本来就是设计成会轮换的。
# 强制 IPv4，目标主机只发布 A 记录
$ curl -4 -s https://v4.example.net/ip
203.0.113.47
# 强制 IPv6，同一台机器、同一分钟，目标主机只发布 AAAA
$ curl -6 -s https://v6.example.net/ip
2001:db8:4a3f:1100:5c2e:91ab:7d40:2e19
# 换成双栈的生产域名，协议栈替你做选择
$ curl -s https://www.example.com/ip
2001:db8:4a3f:1100:5c2e:91ab:7d40:2e19
# 一小时后同样的请求，此时 v6 路径质量下降
$ curl -s https://www.example.com/ip
203.0.113.47检查浏览器的 WebRTC、IP 与 DNS 泄漏信号
服务端查询只能看到抵达它的那一条连接。浏览器侧的检查观察的是浏览器自己能到达什么，这是另一个问题，而且往往信息量更大。Browser Leak Check 通过独立的探测入口分别取得 IPv4 与 IPv6 结果，收集对等连接产生的 ICE 候选，并请求受控权威 DNS 区域下的 50 个一次性子域名，让权威服务器报告实际执行这些解析的递归解析器是谁。
WebRTC 这部分值得准确描述，而不是像多数文章那样制造恐慌。页面创建对等连接时，浏览器会枚举本地网络接口生成 host 候选，并向已配置的 STUN 服务器询问自己的 server-reflexive 地址。现代浏览器已经不会把原始私网地址交给页面：host 候选会以一个随机的 .local 结尾的 mDNS 主机名发布，页面 JavaScript 看不到私网地址，局域网内的对等连接照常工作。真正有信息量的是 server-reflexive 候选，因为那才是远端对等方会看到的地址。如果它和你配置的出口对不上，说明浏览器的媒体流量走了你没打算让它走的路径。
DNS 部分靠的是观察，不是读取配置。没有任何浏览器 API 能读到操作系统的解析器设置，所以唯一诚实的做法，就是让浏览器去解析一批从未被解析过的名字，然后看谁来问权威服务器。这样得到的是实际承担查询的递归解析器，通常也正是你想知道的。读结果时记住两点：大型公共解析器是 anycast 集群，出向查询的地址可能和你联系的那个节点不在同一地区；而做转发的解析器暴露的是它的上游，不是它自己。
把这些信号当作诊断手段。合理的问题是：分流配置是否按照文档把浏览器流量导向了预期路径；受管设备是否在用它应该用的企业解析器；某个地址族是不是悄悄缺失了。结果出乎意料，意味着该去看网络配置了，而不是对配置下结论。
读懂 ASN 与网络类型
查询结果里的 ASN，是宣告覆盖该地址的前缀的那个自治系统，以及登记为其持有者的组织。这是整份结果里最可靠的非平凡字段，因为它来自路由数据和注册记录，而不是统计推断。它也回答了大家实际最关心的问题：这是一张什么样的网。托管与云、家庭宽带、移动运营商、企业专线、教育网，在你的流量沿途遇到的各种系统眼里差别很大；对比两个环境的 ASN，经常就能解释清楚为什么一个老被拦、另一个没事。
有两条边界要说清楚。第一，ASN 告诉你的是谁宣告了这段前缀，不是谁在用这个地址：一家云厂商的 ASN 覆盖着数量庞大且互不相干的客户，所以「数据中心」是对网络的描述，不是对意图的判断。第二，反向解析是弱信号。像 host-203-0-113-47.pool.example-isp.net 这样的 PTR 记录由地址持有方自行设置，没有任何认证，而且经常过期或干脆没有；把它当作佐证注册数据的线索可以，单独当证据不行。
在额度内工作，并让结果可比较
本站的查询服务按访问 IP 的 UTC 自然日计量。IP Info 每天 1000 次，Proxy Check 每天 500 次，Site Check 只有 10 次 —— 因为每次站点检查都是一次真实的出站请求，而不是一次数据库读取。窗口在 UTC 00:00 重置，对大多数读者来说这不是本地的午夜；如果一个批量任务从下午起就一直失败，先算一下你所在时区相对 UTC 的位置，再判断是不是出了故障。
计数以反向代理在 X-Forwarded-For 中上报的访问地址为键。在共享出口的办公室或校园网里，这个地址后面的所有人共用同一份额度。如果一个小组正在同时排查同一起事故，知道这一点，就不会误以为服务在无理限流。
负责任地使用 IP 数据
在不少司法辖区（包括 GDPR 之下），IP 地址在能够关联到个人时属于个人数据。这对实践有直接影响：查询结果保存多久、谁能看到、该不该贴进全公司都能翻阅的工单里。请按照你对待任何其他标识符的留存和访问规则来对待它，也不要去汇集与你没有任何运维关系的地址的查询结果。
最后，对一次检查能证明什么要诚实。查询返回了你预期的地址，只说明这一次请求走了你配置的路径。它不能说明设备发起的其他所有连接，不能说明应用层观察者能关联到什么，也不覆盖浏览器之外的流量。这些工具的用途，是让你搞清楚自己的网络实际在怎么跑、好把它修对 —— 它们是诊断工具，把结论外推成别的什么保证，就是在误用数据。
要点回顾
- 把 IP 结果当成网络出口的一张快照，而不是身份：国家和 ASN 可信，城市和邮编通常不可信。
- 用只发布单一地址族的主机名分别查询 IPv4 与 IPv6，因为双栈浏览器会替你选一个，而路径变慢时答案就会变。
- IPv6 放行运营商委派的前缀而不是单个地址，接口标识本来就会轮换。
- 浏览器的 WebRTC 与 DNS 信号只是观察结果：server-reflexive 候选与预期出口不符，是去检查配置的理由。
- 额度在 UTC 00:00 重置且按访问地址计量，所以把每次结果连同时间戳存下来，别重复查同一个地址。