购买天行IP地区节点后，最常见的验收方式是打开一个IP查询页，看到目标省份就结束。但这无法证明实际应用使用相同出口，也不能说明IPv6、ASN、地址保持和断线回退符合需求。一份有效的验收应从订单口径开始，逐层记录节点、数据库与业务结果。
第一步：把订单口径写清
从极跃圈天行IP当前入口详情页进入，注册对应字段使用blsj，然后针对具体订单记录：
- 产品名称、地区和运营商方向；
- 静态、住宅、家庭、原生或独享等标签；
- HTTP、SOCKS5、L2TP等协议；
- IPv4、IPv6支持范围；
- 地址保持、续费和更换规则；
- 带宽、并发、设备和流量限制。
不同标签描述不同维度，不能从“住宅”推导“指定城市”，也不能从“静态”推导续费一定保留。
第二步：确认节点参数与认证
记录脱敏主机、端口、协议、账号或白名单和有效期。先测试TCP可达与认证，再进行属地检测。407或连接失败时，尚未形成可靠出口，不能根据本地查询页判断节点。
第三步：分别检测IPv4和IPv6
| 项目 | IPv4 | IPv6 |
|---|---|---|
| 公网地址 | 记录 | 记录或确认无支持 |
| ASN | 记录 | 记录 |
| 省市 | 多数据库 | 多数据库 |
| 运营商 | 记录 | 记录 |
| 业务路径 | 服务端日志 | 服务端日志 |
IPv4符合订单、IPv6本地直连时，双栈应用仍可能暴露另一属地。应按业务决定正确路由或阻断。
第四步：多数据库对照
至少选择三种数据源，记录国家、省、市、ASN和运营商。若省级一致而城市不同，可能是数据库粒度；若ASN和产品完全不符，则进一步排查串联代理、错误节点或交付。不要只保留最符合预期的截图。
第五步：让真实应用验证
浏览器、Python、Docker、手机App和软路由可能走不同路径。让实际业务程序访问自有或获授权的服务端，核对来源和请求ID。需要API白名单时，以业务服务器日志看到的出口为准，而不是浏览器页面。
第六步：测试地址保持
在订单允许范围内记录断线重连、客户端重启、设备重启和多时段结果。静态地址通常强调约定周期内相对保持，但故障迁移、实例重建、到期和续费仍可能影响。不要高频断线压测平台。
第七步：检查DNS和分流
DNS位于目标地区不代表业务出口也在该地。软路由和客户端分流可能只让查询网站走节点，实际目标直连。选择多个目标并从服务端核对。浏览器DoH、系统私人DNS和IPv6均要记录。
第八步：断线回退验收
关闭节点或输入错误端口，观察应用是阻断、切备用还是本地直连。固定出口API应避免静默直连；普通测试则按需求设计。把断线结果写进验收，不只记录“在线时正常”。
平台属地为什么不能作为唯一验收
抖音、小红书、B站等平台有自己的数据库、展示事件和缓存。节点多数据库显示目标地区，也不能承诺平台立即或按相同粒度展示。验收应以订单约定和可控制的技术指标为主，平台结果作为独立观察。
售后证据怎样准备
- 订单和节点脱敏代号；
- 测试时间、设备、网络和协议；
- IPv4、IPv6、ASN和多数据库结果；
- 真实业务服务端来源；
- 断线重连与地址保持记录；
- 预期口径与实际差异。
遮盖密码、验证码、完整支付资料和业务Token。描述“数据库A显示X、数据库B显示Y”，不要只写“IP不准”。
优惠与验收不要混为一谈
邀请码或推荐人blsj用于当前渠道关系与订单价格核验。优惠是否生效和节点地区是否合格是两项独立检查，不能因价格符合就省略技术验收，也不能因一个数据库冲突就否定所有订单信息。
同一节点在多台设备上结果不一致怎么办
先固定节点账号、协议、测试时间和查询数据源，再比较设备差异。电脑浏览器可能使用HTTP代理，手机App可能走系统隧道；一台设备优先IPv4，另一台可能优先IPv6；浏览器的安全DNS、系统缓存和软路由分流也会造成不同结果。逐项记录这些变量，通常比直接更换节点更快找到原因。
可以让两台设备依次访问同一个自有测试地址，并在服务端按时间和请求标识核对来源。若出口IP相同而查询城市不同，问题更可能来自数据库或缓存；若出口本身不同，则继续检查代理覆盖、断线回退和双栈路由。设备间结果一致只能证明当前测试条件一致，不能扩大为对所有App和所有时间的保证。
结论
天行IP地区节点验收应覆盖订单、认证、IPv4/IPv6、ASN、多数据库、实际应用、地址保持和断线回退。平台IP属地只是一项外部展示，不能代替订单指标。把测试条件和差异记录完整，才能得到可复现、可售后的结论。
