ipaudit：输入一个 IP，告诉你它能不能用、为什么
前言
做跨境电商、广告投放的朋友应该都遇到过这个处境：花几块钱买了个「独享住宅 IP」，店铺说封就封。去问服务商，对方说「我们的 IP 是干净的」；自己排查，又不知道从哪查起。换一家再买，还是封——于是开始怀疑是不是自己操作有问题。
这事我看了很久，发现一个问题：这个市场上没有任何一方能拿出证据。卖家说 IP 干净，拿不出检测报告；买家觉得 IP 脏，也说不清脏在哪。大家都在凭感觉做生意。
所以我写了 ipaudit：输入一个 IP，输出一份「这个 IP 到底干不干净、以及为什么」的可验证报告。每一条判定都带证据来源和扣分值，拿到报告的人可以自己复核——「可被复核」是这个工具区别于凭感觉说话的全部价值。
先说定位：卖判断力，不卖通道。它不做代理、不做隧道、不帮你绕过任何平台的检测，只告诉你真相。
三条红线
这类工具有几条不能碰的线，我直接写进了代码结构，不是免责声明：
| 红线 | 落地方式 |
|---|---|
| 只检测，不代理 | 端口探测只做握手确认，确认即断开，不建立数据通道 |
| 只诊断，不伪装 | 不提供指纹伪造、UA 篡改等「通过检测」功能 |
| 只存结论，不存关联 | 数据库里刻意不存账号/店铺/备注，只有会话 token 和 IP |
第一条最难守，因为它最赚钱——但一旦做了通道，价值反而下降：卖通道的人遍地都是，卖判断的人几乎没有。
两个维度：回答「我为什么封号」
这是整个设计里我最看重的一个判断。市面上能查 IP 的网站不少，但它们只覆盖了一半：
- IP 维度（服务端可查）：这个 IP 本身的属性和历史——是不是真住宅、进没进黑名单、开没开代理。
- 环境维度（必须浏览器实测）：你的浏览器长什么样——时区、语言、字体、WebRTC 有没有泄漏真实 IP。
只有两个维度交叉，才能回答客户真正想问的问题：「我为什么封号」。
典型场景：IP 是 100 分的干净真住宅，但浏览器时区是 Asia/Shanghai、语言 zh-CN、WebRTC 把真实 IP 裸奔了出去——平台一眼就看出「这个美国用户在用一台中国电脑」。这种封号，换多少 IP 都没用。 报告会直接告诉你：环境维度不达标，先修浏览器，别浪费钱换 IP。
IP 维度：四路证据投票
判定一个 IP 是不是「真住宅」不能只看 ASN 名字，我用了四路证据加权：
- ASN 分类表：人工维护的 160+ 条 ISP/机房分类（这份表本身就是资产，一季度补一次）
- rDNS 命名模式：
c-73-12-45-8.hsd1.ca.comcast.net是典型住宅；ec2-x-x-x.compute-1.amazonaws.com是典型机房 - /24 网段粒度：住宅段动态分配、命名各异；机房整段持有、命名同构（深度模式抽样 16 个地址验证）
- 第三方标注：ipapi.is、ip-api 的 datacenter/hosting 标注投票
关键是冲突消解：有强机房信号时，其他证据再好也不能判「真住宅」——否则「Comcast 的 ASN + EC2 的 rDNS」这种矛盾组合会被多数票洗成真住宅。
环境维度：WebRTC 四态，不是只有漏/不漏
浏览器探针在绑定了目标 IP 的环境里打开，实测时区、语言、字体集、WebRTC、Canvas 指纹，提交后服务端与 IP 维度交叉比对。
WebRTC 这块我特意做了四态分类，因为「收集不到 candidate」有两种完全相反的原因：
| 状态 | 含义 | 处理 |
|---|---|---|
leak |
公网 IP 暴露，或内网 host 外泄 | −25，最高优先级修复项 |
restricted |
只有 srflx（出口 IP），无 host | 合规 |
disabled |
零 candidate（已禁用） | 不扣分，但记为环境特征——某些平台视为异常指纹 |
blocked |
探针被拦截 | 标 unavailable，不能当通过 |
把 disabled 和 blocked 都当成「安全」是这个领域最常见的自欺。
修复闭环：精确到配置项
检测到泄漏时，探针页就地给出修复方法，改完点「WebRTC 复测」重新采集，评级实时回升。推荐顺序：企业策略 > 启动参数 > 扩展。
以 Chrome 为例，--webrtc-ip-handling-policy=disable_non_proxied_udp 是四个可选值里唯一能同时挡内网 IP 和直连公网 IP 的——但有三个前提：必须完全退出浏览器再启动（旧实例会把参数当 URL 丢弃，这是「加了参数怎么还漏」的头号原因）、写进快捷方式、排查会自建连接的扩展。指纹浏览器的 WebRTC 设置实现质量参差，设置项显示已关不等于真关了——所以改完必须复测，这正是探针页存在的理由。
诚实降级：把「查不到」和「没问题」分开
这个领域最普遍的自欺是把「查不到」当「干净」。我在采集层立了一条铁律：六单元全并行、各自超时、任一失败不阻断，失败项标 unavailable 并写明原因。报告里有一块专门的「未测到（不代表干净）」。
一个必须踩的坑：Spamhaus 会拒绝来自公共 DNS 解析器（8.8.8.8 / 1.1.1.1）的查询，返回 127.255.255.254——这个码的意思是「查询无效」，不是「命中」。常规写法「返回 127.x 就算命中」会得到一片假阳性。类似地，hostkarma 的 127.0.0.2 是黄名单（中性语义），Google DNS 都挂着它，当命中扣分必误判。这些都是踩过之后才写进代码注释的。
标定：21 个 IP，判准率 100%
评分模型不标定就是拍脑袋。我建了一个基准集：10 个真住宅段（Comcast/Verizon/AT&T/SoftBank/CMNET 等）+ 11 个机房与公共 DNS 段（AWS/Cloudflare/Tor 出口/CDN77 等），跑四路证据投票。
首轮正确率只有 67%，暴露了几个真问题：基建 IP 的 rDNS 必然与 org 同源，这条不能当住宅证据；Cloudflare 该判机房而不是中性；我自己的基准集还标错了一个 IP（84.17.46.1 是 CDN77 机房，不是德国住宅）——系统判对了，出题人错了。修完之后 21/21 = 100%，明细（含每个 IP 的四路证据得分）在 calibration/result.json。
工程侧
零依赖：只用 Python 标准库。DNS 查询自己实现报文（A/PTR 两种、约 200 行，防投毒的随机源端口 + 事务 ID 都有）；本地 API 用 http.server；前端和探针都是单文件 HTML 内嵌进 exe。核心价值在判定逻辑，多一层框架就多一层排错成本。
扣分制评分：从 100 起扣，不用加分制——加分制会让「什么都没查到」得高分，而「什么都没查到」和「查了很干净」是两回事。同层取最严重不叠加，避免重复惩罚。
监听与访问控制：DNS 解析器（unbound）只听 127.0.0.1 或 WireGuard 内网，access-control 白名单 + 0.0.0.0/0 refuse 兜底 + 防放大参数；开放递归 = 被扫成放大器 = 自己的 IP 进 Spamhaus DROP，等于自毁招牌。HTTP 服务无鉴权机制，所以只允许回环绑定，非回环直接拒绝启动。部署后用 resolver-check --recursion-test 从外部验证。
打包：PyInstaller 单文件 exe（约 9MB），双击进交互菜单。踩过一个隐蔽的坑：单文件模式下数据路径不能用 __file__ 推导——它指向每次启动都换的解包临时目录，数据等于写在沙子上，必须用 sys.executable 定位 exe 同级。
结尾
这个工具现在是自用 + 给身边做跨境的朋友排查问题。四层形态里目前落地了三层：CLI/exe（免费）、批量 HTML 报告、监控订阅的技术底座（定时复检 + webhook 告警）。
源码在 GitHub，零第三方依赖，python -m ipaudit 8.8.8.8 就能跑。老规矩：只检测，不代理；只诊断，不伪装——它不会帮你过任何平台的检测，它只让你知道自己在什么位置上。