住宅IP检测方法大全：ASN归属、欺诈评分、BGP路由、DNS泄露——5维技术验证框架

去年帮一个做 TikTok 矩阵的朋友排查账号批量被封的问题，他买了 20 个所谓「美国原生住宅 IP」，结果注册完不到 48 小时全部阵亡。排查后发现，那批 IP 里有 14 个的 ASN 归属是 DigitalOcean 和 Hetzner——典型的数据中心 IP 套了层住宅代理的壳。从那时候起我就养成了一个习惯：不管从哪个渠道拿到 住宅IP，先跑一遍检测流程，再投入业务使用。

这篇文章就是把我和身边朋友在实际业务中踩过的坑、总结出来的检测方法整理成一套可复用的框架。不会只给你一个工具列表让你自己去试——而是沿着「这个 IP 是谁的 → 有没有案底 → 链路有没有穿帮 → 路由有没有问题」这条逻辑链，把每一层该看什么、怎么看、看到什么数据算合格，一步一步拆开讲清楚。

目录

• 一、为什么需要主动检测住宅IP
• 二、检测维度一：IP 归属信息验证
• 三、检测维度二：IP 类型数据库交叉验证
• 四、检测维度三：欺诈评分——查 IP 的「案底」
• 五、检测维度四：DNS 与 WebRTC 一致性
• 六、检测维度五：BGP 路由验证
• 七、工具横向对比与完整实操流程
• 八、IP 纯净度：不止于「真伪」
• 九、常见误判场景与避坑指南
• 常见问题 FAQ

一、为什么需要主动检测住宅IP

做跨境电商、社媒运营或者数据采集的朋友可能都有类似的经历：花钱买了 住宅代理，配置看起来一切正常，但一到实际业务场景就开始翻车——TikTok 注册秒封、Amazon 页面返回验证码、Google 搜索直接弹出人机验证。

问题往往不出在代理协议本身，而是出在 IP 上。

市面上的「住宅 IP」鱼龙混杂，最常见的有两种坑：一种是数据中心 IP 冒充住宅 IP——托管服务商的 IP 段被当成住宅 IP 来卖，whois 一看就是 DigitalOcean 或者 AWS 的；另一种是被污染的住宅 IP——IP 确实是住宅的，但因为前一个用户（或者共享池里的其他人）做过垃圾注册、批量爬取之类的操作，这个 IP 已经被多个平台的风控系统打上了标记。

不管是哪种情况，结果都一样：你还没开始用，IP 的信誉就已经透支了。

所以我个人的做法是，把检测当作使用前的固定环节——跟买车前查 VIN 码、租房前查周边环境一样，花五分钟跑一遍检测，比事后花几小时排错要划算得多。

二、检测维度一：IP 归属信息验证

先搞清楚「这是谁的 IP」

拿到一个 IP 地址，第一个要回答的问题不是「它干过什么」，而是「它到底是谁的」。这就像查一个人的身份证——先确认身份信息，再查信用记录，顺序不能反。

IP 归属信息的核心是三个东西：ASN（自治系统编号）、ISP 名称和IP 段的宣告来源。这三者结合在一起，能让你在几十秒内判断出一个 IP 到底是真住宅还是伪装的。

第一步：查询 ASN 归属

ASN 是互联网上每个网络的身份编号。每个 IP 段都属于某个 ASN，而 ASN 的注册类型直接决定了这个网络的「出身」：是家庭宽带运营商的网络，还是云计算/托管服务商的网络。

最直接的方式是通过 ipinfo.io 查询。打开页面输入你要检测的 IP，重点看两个字段：

asn.name：ASN 的注册名称。如果看到 “Comcast Cable Communications”、”AT&T Services”、”Spectrum”、”ChinaNet” 这类名称，基本可以确认这是 ISP 类网络。如果看到 “DigitalOcean, LLC”、”Amazon.com, Inc.”、”Hetzner Online GmbH”，那就很可疑了。

asn.type：ipinfo 对 ASN 的分类标签。"isp" 表示互联网服务提供商，是住宅 IP 的主要来源；"hosting" 或 "business" 需要进一步判断。

下面这个表格把常见的判断信号做了一个分类，日常做快速筛选的时候可以直接对照：

表 1：IP 归属信号红绿灯对照表

第二步：用 RDAP 协议做二次确认

不要只信一个数据源。ipinfo 再权威，它的数据也有滞后性。建议再用 RDAP（Registration Data Access Protocol，RFC 7482 标准）做一次交叉确认。

RDAP 是 whois 协议的现代替代方案，直接查询 IP 在区域互联网注册机构（RIR）的原始注册数据。它的优势在于数据来自官方注册机构（ARIN、RIPE NCC、APNIC 等），不受第三方数据库更新延迟的影响。

命令行方式查询一个 IP 的 RDAP 数据：

curl -sL https://rdap.org/ip/8.8.8.8 | jq -r '.name'

rdap.org 是全球通用的 RDAP Bootstrap 引导节点（RFC 7484），它会自动将查询重定向到该 IP 所属区域注册机构（RIR）的正确端点——查北美 IP 转 ARIN、查亚太 IP 转 APNIC、查欧洲 IP 转 RIPE NCC。如果你更习惯使用 ARIN 的域名，正确的引导路径是 /bootstrap/ 而非 /registry/：

curl -sL https://rdap.arin.net/bootstrap/ip/8.8.8.8 | jq -r '.name'

注意：ARIN 的 /registry/ 路径是专属的直接查询节点，不会进行跨区域重定向——查询非 ARIN 管辖的 IP 只会返回「未找到」报错，而非转接到 APNIC 或 RIPE。-L 参数在 /registry/ 路径下对于非 ARIN 管辖 IP 实际上不会触发任何重定向。真正的 Bootstrap（引导）端点才是 /bootstrap/ 路径，或直接使用 rdap.org 这个全球引导节点。

如果返回的 .name 是家庭宽带运营商（如 “Comcast Cable Communications, LLC”）或电信运营商 ASN 名称（如 “ChinaNet”），那归属信息这关基本过了；如果是 “DigitalOcean, LLC” 或 “Hetzner Online GmbH”，可以直接判定为非住宅 IP。

关于 RDAP 协议的完整规范，可以参考 RFC 7482 和 RFC 9083。

第三步：注意「伪住宅 ASN」的陷阱

有一种情况需要特别警惕：部分代理服务商会专门注册 ISP 类型的 ASN，然后在这个 ASN 下宣告原本属于托管网络的 IP 段。光看 ASN 类型可能被迷惑，这时候就要用到第五个维度——BGP 路由验证来做终审。

三、检测维度二：IP 类型数据库交叉验证

别信一家之言

做完归属验证之后，下一步是用多个独立的 IP 数据库交叉比对，确认这个 IP 的「类型标签」是否一致。

为什么需要这一步？因为不同的 IP 数据库有各自的分类标准、数据来源和更新机制。同样是判断一个 IP「是不是住宅 IP」，MaxMind 和 ip2location 可能给出不同的结论——MaxMind 主要依据 ISP 类型分类，ip2location 则结合了更多的行为数据和用户反馈。

下面把日常最常用的几个数据库做一个横向对比，方便你根据自己的场景选择组合：

表 2：主流 IP 数据库能力对比

交叉验证的规则

我自己的习惯是这样的：

• 日常快速筛选：IPinfo（看 ASN 归属）+ Scamalytics（看欺诈评分），两个数据库够了
• 采购前的质量审计：IPinfo + Scamalytics + ip2location，三个数据库交叉，两个以上判定「住宅」才算初步可信
• 高价值单 IP 审计：再加 IPQualityScore 的 Fraud Score 和 AbuseIPDB 的历史报告，五个维度全覆盖

交叉验证的过程本身也是在建立一套自己的判断基准。数据库不是绝对真理，但多库交叉比对能大幅降低误判概率。

四、检测维度三：欺诈评分——查 IP 的「案底」

归属没问题，不代表信用没问题

IP 归属验证和数据库交叉比对回答的是「这个 IP 是谁的」，欺诈评分回答的是另一个更重要的问题：「这个 IP 干过什么」。

一个住宅 IP 在技术层面完全真实——ASN 是 Comcast、地理位置在美国加州、路由路径一切正常——但它可能在过去 30 天内被报告过发送垃圾邮件、参与过 DDoS 攻击，或者被多个平台标记为「高风险」。这些信息不会出现在 ASN 查询结果里，但会直接导致你的 TikTok 账号注册失败、Amazon 订单被风控拦截。

欺诈评分就是把这类历史行为数据量化成一个 0-100 的分数。分数越低，说明这个 IP 的历史记录越清白。

表 3：欺诈评分工具对比

日常使用中，IPQS 和 Scamalytics 可以互补。IPQS 的数据维度更全（能单独告诉你这个 IP 是不是 Proxy、VPN、TOR、Bot），适合做精细化的单 IP 审计，但免费额度较少（每月 1,000 次）；Scamalytics 侧重欺诈风险评分，操作门槛更低，免费额度较大（每月 5,000 次），适合做批量快速初筛。

我的常规流程是：先用 Scamalytics 跑一遍做初筛，Fraud Score 超过 25 的直接 pass（Scamalytics 标准）；剩下的再用 IPQS 做精细评估，IPQS Fraud Score 超过 74 分才需要警惕或更换（IPQS 标准）。

表 4：IPQS 检测指标判定标准

有几个注意点值得单独说一下：

Fraud Score = 0 不代表绝对安全。一个新的、几乎没被使用过的住宅 IP，它的历史记录确实是一张白纸，分数自然就是 0。但这不代表它在未来使用过程中不会触发目标平台的风控。欺诈评分是「历史清白度」，不是「未来安全保证」。

共享 IP 池的评分可能不是你的锅。动态住宅代理的 IP 来自 P2P 共享网络，同一个 IP 可能被不同用户用于不同目的。你在用这个 IP 做正常的社媒运营，但上一个人可能用它发过垃圾邮件——这个评分记录会跟着 IP 走。

定期复检比一次性检测更重要。尤其是动态 IP，每次轮换到新 IP 时都应该跑一遍检测。即使是 静态住宅IP，也建议每周做一次复检，因为 IP 的信誉状态可能在持续变化。

AbuseIPDB 的使用场景和前两者略有不同。它更适合在你已经对一批 IP 做了初筛之后，对少数几个「看起来还行但不太确定」的 IP 做深度的历史背景调查。输入 IP 后看一下 Abuse Confidence Score（滥用置信度）和 Total Reports（累计报告数）——如果置信度超过 5% 或者最近 30 天有新的滥用报告，建议谨慎使用。

五、检测维度四：DNS 与 WebRTC 一致性

链路有没有「穿帮」

前面三个维度都是在检测 IP 本身的质量——它是不是住宅 IP、历史记录好不好。但从第四个维度开始，我们要换一个角度：代理链路本身有没有漏洞。

简单说就是：你通过代理访问目标网站的时候，有没有「信息泄露」的问题。最常见的是两种：DNS 泄露和 WebRTC 泄露。

DNS 泄露是怎么发生的

DNS 泄露的原理其实很好理解。代理工具一般只代理 HTTP / HTTPS 流量（应用层），但 DNS 查询请求可能在操作系统层面就走了本地网络——相当于你用了代理的 IP 去访问网站，但域名解析请求是从你真实的网络发出的。目标网站的风控系统一比对：请求来自美国住宅 IP，但 DNS 查询来自中国某地——这个不一致本身就是一条「你是代理用户」的证据。

检测方法很直接。连上代理之后，打开 ipleak.net 或者 dnsleaktest.com，看一下页面上显示的 DNS 服务器地址：

• DNS 服务器地址的地理位置应该和代理 IP 属同一地区（至少同一国家）
• 如果同时出现了多个 DNS 服务器，且地理位置各不相同，说明部分 DNS 请求可能走了本地、部分走了代理——这也是泄露
• EDNS Client Subnet（ECS）值应当显示为「无」（None），或者显示为代理服务器自身的 IP 子网。只要 ECS 显示的不是你真实的本地物理宽带网段，就不属于隐私泄露。 根据 RFC 7871 规范的运作流程，普通的客户端（Stub Resolver，如你的电脑或浏览器）在发起 DNS 请求时通常不会自己携带 ECS 发给递归服务器。真实的流程是：你的电脑向 DNS 递归服务器（如 8.8.8.8）发起普通请求 → 递归服务器为了优化 CDN 调度，由递归服务器向权威 DNS 服务器添加 ECS 扩展，告知客户端（或代理节点）所在的子网。当你使用 SOCKS5 代理并开启「远程 DNS 解析」时，ECS 携带的是代理服务器的 IP 子网——这是用于让 CDN 分配离代理服务器最近节点的正常机制。只有当 ECS 显示的子网段恰好属于你本地真实的物理宽带 ISP（如中国电信/中国联通）时，才说明 DNS 解析没有走代理、发生了真实 IP 泄露。

WebRTC 泄露的原理与检测

WebRTC 泄露比 DNS 泄露更隐蔽。WebRTC 是浏览器内置的实时通信协议，它通过 STUN（Session Traversal Utilities for NAT，RFC 8489 标准）协议来获取设备的真实 IP 地址，目的是建立 P2P 连接。问题是——即使你用了 HTTP 代理，WebRTC 的 STUN 请求依然可能绕过代理，直接暴露你的真实 IP。

关于 STUN 协议的详细机制，可以参考 RFC 8489。

检测 WebRTC 泄露用 browserleaks.com/webrtc 就够了。连上代理之后打开这个页面，重点看两个区域：

• Local IP Address：自 Chrome/Edge 86 起，现代浏览器默认启用了 mDNS 混淆技术来保护本地网络隐私。正常情况下这里应显示为空，或者显示形如 1bbabc05...local 的虚拟 mDNS 主机名——这是浏览器正常的隐私保护行为，不是泄露。如果这里直接出现了 192.168.x.x 的明文内网 IP（常见于旧版浏览器或未启 mDNS 的配置），才说明 WebRTC 可能暴露了内网信息。
• Public IP Address：应该只显示代理的公网 IP。如果出现了多个 IP 或者与你本地网络匹配的 IP，同样是有泄露。

表 5：DNS 与 WebRTC 泄露检测工具

如果发现泄露怎么办

DNS 泄露的修复相对简单：改用支持 DNS 代理的协议（如 SOCKS5），并且在代理工具或浏览器中强制启用「远程 DNS 解析」选项——这两个条件是绑定的。以 Firefox 为例，仅配置 SOCKS5 代理是不够的，还必须将 network.proxy.socks_remote_dns 设为 true，否则 DNS 请求仍会从本地网络发出。根据 SOCKS5 协议标准（RFC 1928），代理并不强制接管客户端的 DNS 请求，这一步需要显式配置。

WebRTC 泄露的修复要看浏览器：

• Firefox：在地址栏输入 about:config，搜索 media.peerconnection.enabled，设置为 false。这是最简单粗暴且有效的方式。
• Chrome：原生不支持彻底关闭 WebRTC，需要安装专门的扩展（如 WebRTC Leak Prevent 或 uBlock Origin 的 WebRTC 阻止功能）。自 Chrome 86 起，浏览器默认通过 mDNS 混淆内网 IP，Public IP 一般也不会泄露，但对于高安全需求场景仍建议安装扩展。
• 基于 Chromium 的指纹浏览器：多数内置了 WebRTC 泄露防护，在设置中确认「阻止 WebRTC 泄露」选项已开启即可。

六、检测维度五：BGP 路由验证

从路由层面找「伪装者」

如果说前面四个维度是常规检查，那第五个维度就是「技术终审」。

BGP（Border Gateway Protocol）是互联网的核心路由协议，简单理解就是一张全球网络的「路由地图」。每个 IP 段通过 BGP 在互联网上宣告自己的归属路径——从哪个 ASN 出发、经过哪些中间网络、最终到达哪里。

这个路径信息是做不了假的：如果一个 IP 真实归属于 Comcast 的住宅网络，它的 BGP 宣告路径必然是从 Comcast 的 ASN（AS7922）出发；如果一个 IP 的实际来源是 DigitalOcean 的机房，无论你给它贴上什么标签，它的 BGP Origin AS 依然是 DigitalOcean（AS14061）。

用 Looking Glass 工具验证路由

验证 BGP 路由不需要自己搭建 BGP 路由器。有几个公开的 Looking Glass 工具可以直接用：

• bgp.he.net：Hurricane Electric 提供的免费 BGP 查询工具，输入 IP 就能看到 Origin AS 和 Prefix。操作门槛最低，推荐优先使用。
• stat.ripe.net：RIPE NCC 的路由信息服务平台，可以看到 IP 段的路由宣告历史。适合做更深入的分析，比如查看一个 IP 段在过去 12 个月内是否发生过 ASN 变更。
• lg.he.net：Hurricane Electric 的 Looking Glass 路由器，可以在全球多个节点执行 show ip bgp <IP> 命令，查看完整的 AS Path。

表 6：BGP 路由异常信号对照表

关于 AS Path 跳数的补充说明：BGP AS Path 的长度主要取决于查询节点（Looking Glass）与目标 ASN 之间的拓扑连接关系，与 IP 是否属于住宅网络没有直接关联。当 Looking Glass 所在的网络与住宅 ISP 存在直接互联（Direct Peering）时，AS Path 为 1 跳或 2 跳是完全正常的现象——这仅代表该运营商的网络连通性好、逻辑距离近。例如，Hurricane Electric（bgp.he.net 的运营方）与 Comcast、AT&T 等大型住宅运营商之间存在直接互联，从 HE 的 Looking Glass 查询 Comcast 住宅 IP 时，AS Path 往往只有 1-2 跳。因此，AS Path 跳数不能作为判断 IP 类型的技术指标，更不应将其标记为风险信号。

关于 /24 段内多 ISP 的说明：根据全球 BGP 路由安全规范（MANRS）及 RFC 7454 标准，IPv4 在 Default-Free Zone 中被允许接受和传播的最小前缀长度为 /24。任何小于 /24（如 /25、/26 等）的细分宣告都会被骨干路由器直接过滤丢弃。因此，通过 BGP Looking Glass 是无法观测到一个 /24 网段被切分给多个不同 ISP 的——这种现象只存在于商业 IP 数据库的内部子分配记录中，属于数据库层面的信息，不是 BGP 路由层面的可观测数据。

日常使用中，BGP 验证不需要每个 IP 都做。我的建议是：

• 日常快速筛选：维度一（归属）+ 维度三（欺诈评分）已经能过滤掉 90% 以上的问题 IP，不需要跑 BGP
• 采购前质量抽检：从要采购的 IP 池里随机抽 3-5 个跑 BGP 验证，如果有一个出现异常，整个批次都值得重新评估
• 高价值业务 IP 审计：用于长期账号运营、金融交易等对 IP 稳定性要求极高的场景，每个 IP 都跑一遍 BGP 验证

七、工具横向对比与完整实操流程

先把工具看清

前面五个维度讲完，涉及的工具加起来有七八个。下面这张表把这些工具的覆盖维度、免费额度和适用场景做一个汇总，方便你根据自己的实际需求挑选组合：

表 7：检测工具横向对比总表

完整 5 步实操流程

下面是一套我日常在用的完整检测流程，适合 住宅IP购买 后对新到手的 IP 做全面质量审计。每一步都标了预计耗时和通过标准，跟着走就行：

表 8：住宅IP 完整 5 步检测流程

Step 5 是最后一道防线。前四步验证的是技术层面的合规性，但最终能不能用、好不好用，还是要看目标平台的实际反应。同一个 IP，在 ipinfo 上标注「住宅」、欺诈评分 5 分、DNS 和 WebRTC 全绿——但 TikTok 就是不给注册——这种情况并不少见。因为每个平台的风控模型有自己独立的 IP 信誉数据库，不对外公开。

实战验证时建议做的事情：

• 注册一个新账号（不要用老号测试，老号的设备和行为历史会干扰判断）
• 完成基础的账号设置（头像、简介等），观察是否触发验证码或身份验证
• 至少正常使用 24 小时后再做结论——有些平台的延迟风控会在几小时甚至一两天后才触发

日常快速筛选版

不是每次都需要跑完整 5 步流程。日常使用的时候，我一般只跑一个精简版：

1. ipinfo.io → 看 ASN 类型和 ISP 名称（30 秒）
2. Scamalytics → 看 Fraud Score（30 秒）
3. browserleaks.com/webrtc → 看有没有泄露（1 分钟）

两分钟搞定，能过滤掉绝大部分有明显问题的 IP。

八、IP 纯净度：不止于「真伪」

从「能不能用」到「好不好用」

前五个维度帮我们判断一个 IP 是不是真的住宅 IP、有没有技术层面的问题。但实际业务中，还有一个更高层次的概念值得关注——IP 纯净度。

有一些住宅 IP，归属验证没问题、欺诈评分为零、路由也一切正常，但在实际使用中频繁触发目标平台的风控，表现甚至不如一些「看起来不那么像住宅」的 IP。问题就出在纯净度上。

IP 纯净度不是单一指标，而是由三个层面决定的综合状态：

一是历史清白度。一个 IP 在过去是否被报告过滥用、是否在黑名单上、是否被多个平台标记。这和欺诈评分类似，但比欺诈评分更广——某些平台内部的黑名单并不会反映在公开的欺诈评分 API 里。

二是画像稳定性。一个长期（6 个月以上）稳定归属于同一 ISP、同一 ASN、同一地理区域的 IP，比一个频繁在不同 ISP 之间切换的 IP 更「可信」。目标平台的风控模型倾向于信任「行为稳定」的 IP。

三是使用隔离度。同一个 IP 在同一时间段内是否被多个账号同时使用、是否被用于性质差异很大的不同业务（比如一边做 TikTok 运营一边批量爬 Google）。使用密度越高、业务类型越杂，IP 被风控标记的概率越大。

在英文语境的代理服务市场中，这个概念对应的是 clean residential proxies——干净的住宅代理。它的核心特征就是低共享度、历史滥用记录为零、长期稳定归属于单一住宅 ISP。如果你在选择住宅 IP 服务的时候特别看重质量而非价格，关注这个分类会更有针对性。

九、常见误判场景与避坑指南

不是所有「异常」都代表有问题

检测做多了，也会遇到一些「看起来异常但实际上是正常情况」的场景。下面列三个最常见的误判情形。

CGNAT 导致的欺诈评分偏高

CGNAT（运营商级 NAT）是指运营商让数百个家庭用户共享同一个公网 IPv4 地址。这种场景下，你拿到的是一个真实住宅 IP——但它同时被几百个真实家庭用户共享。

问题在于，这几百个用户里只要有一个做过违规操作（比如发垃圾邮件、参与 DDoS），这个共享 IP 的欺诈评分就可能被拉高。你什么都没做，但 IP 的「案底」已经有了。

需要特别注意的是，CGNAT 并不局限于移动网络。根据 IETF 规范 RFC 6598（IANA-Reserved IPv4 Prefix for Shared Address Space），由于全球 IPv4 地址早已严重枯竭，目前绝大多数固定住宅宽带网络（FTTH 光纤、Cable 同轴电缆、Starlink 等卫星宽带）同样在大规模使用 CGNAT。真实的固定住宅宽带——即使 ISP 标签为纯正的 “ISP” 或 “Fixed”——也可能处于 CGNAT 环境中。

判断一个 IP 是否处于 CGNAT 环境，不能仅凭 ISP 名称中是否包含 “Wireless” 或 “Mobile”。更准确的方法是结合多个信号综合判断：通过 whois 或 RDAP 查询确认 IP 段所属组织是否为明确的住宅 ISP（而非托管/云服务商）；同时观察欺诈评分是否偏高但 AbuseIPDB 的滥用报告量很低——这种「住宅 ISP + 偏高欺诈 + 低滥用报告」的组合，往往是 CGNAT 共享效应的典型表现。

移动网络 IP 被误判为住宅 IP

4G/5G 移动网络的 IP 在某些数据库中会被标注为 “Cellular” 而非 “Residential”，但实际使用效果和住宅 IP 非常接近。部分代理服务商会将移动网络 IP 和住宅 IP 混在一起提供，这在欧美市场是比较普遍的做法。

如果你用 ipinfo 查到一个 IP 的 ASN 是 T-Mobile 或 Verizon Wireless，不要直接判定为「不是住宅 IP」。移动网络 IP 在大多数场景下可以正常使用，但某些对 IP 稳定性要求极高的平台（比如金融交易类）可能对蜂窝网络的 IP 接受度略低。

评分波动是正常现象

欺诈评分不是一成不变的。一个 IP 今天的评分是 10，一个星期后可能变成 25——不是因为你这周做了什么，而是因为其他共享用户的行为影响了评分。

表 9：检测结果误判场景对照

基于以上这些情况，我在实际使用中养成了几个习惯：购买前检测一次（建立基线），使用中每周复检一次（监测变化），发现异常不急于下结论（先确认是 CGNAT 共享效应还是真的被污染），以及不要过度依赖任何单一检测结果（交叉验证永远比单点判断更可靠）。

常见问题 FAQ

免费的 IP 检测工具有哪些？

ipinfo.io 提供每月 50,000 次免费查询，适合日常归属和 ASN 验证；Scamalytics 提供每月 5,000 次免费欺诈评分查询，适合批量初筛；browserleaks.com 无限免费，适合 DNS 和 WebRTC 泄露检测。三者组合覆盖了日常检测的核心需求。如果需要更深度的高价值 IP 审计，IPQS 提供每月 1,000 次免费查询，包含 Proxy/VPN/TOR/Bot 等细分子项。

欺诈评分到底多少算合格？

Scamalytics 与 IPQS 的评分基准完全不同，不可混用。Scamalytics：0-14 分为低风险，0-25 分为可接受范围，超过 25 分建议更换。IPQS：0-74 分为安全区间，75-84 分为可疑，≥ 85 分为高风险——IPQS 只要在 0-74 分之间均属正常可用范围，超过 75 分才需要警惕或更换。注意欺诈评分为 0 不代表绝对安全——全新的 IP 也可能因为缺乏使用历史而得到低分。

怎么快速判断一个 IP 到底是不是机房的？

最简单的三步判断法：第一步，在 ipinfo.io 查 ASN 类型，看到 hosting / cloud / data center 直接排除；第二步，看 org 字段，对标的如果是 DigitalOcean、AWS、Hetzner、Vultr 等云厂商，99% 是机房 IP；第三步，如果前两步不确定，打开 bgp.he.net 查 BGP Origin AS 编号，再到 IPinfo 或 MaxMind 中确认该 ASN 的商业类型——如果被归类为 Hosting / Data Center，可以基本确定非住宅 IP。

住宅 IP 检测需要多长时间？多久检测一次？

完整 5 步流程约 10-15 分钟；日常快速筛选（ipinfo + Scamalytics + browserleaks）仅需 3 分钟。关于检测频率：新购买的 IP 建议跑一次完整流程建立基线；使用中建议每周至少复检一次；使用动态住宅代理时，每次 IP 轮换到新地址后都应该快速跑一遍前三个维度的检查。

为什么 IP 检测全绿，但 TikTok 还是注册不了？

IP 只是风控中的一个维度。即使 ASN 是住宅、欺诈评分 0、无泄露，TikTok 仍可能因为以下原因拒绝注册：平台有自己的内部 IP 信誉库（不对外公开）、设备指纹不一致（浏览器环境与 IP 地区不匹配）、注册行为频率异常（短时间内多次注册）、或者该 IP 段在同一平台上已经被大量账号使用。建议在 IP 检测通过后，配合独立的浏览器环境和合理的操作节奏进行多次测试。