做代理 IP 六年，我见过最冤的封号不是资料问题，而是查错了 IP。ipconfig 看到 192.168，就以为平台看到的也是这个地址。二审邮件往往就是这么来的。这篇文章把「内网 IP、公网 IP、代理出口」三个概念彻底拆开，给出四种必须重新查的场景和三种查法，读完你不再拿内网地址当验收依据。
目录
内网 IP、公网 IP、代理出口，三回事
192.168 / 10.x.x.x 为什么平台看不到
你家里的路由器、公司交换机、云手机虚拟网卡，都会给设备分配一个内网地址。常见段有 192.168.x.x、10.x.x.x、172.16.x.x ~ 172.31.x.x，这些属于 RFC 1918 定义的私网地址。它们的共同特点是：只在局域网内唯一，在互联网上不可路由。
Windows 上执行 ipconfig，Mac 上打开系统设置的网络面板，看到的大概率就是这类地址。它只能说明「这台电脑在本地网络里的编号」，不能说明「平台看到的你」。如果拿 192.168.1.105 去问这是不是美国 IP，答案是否定的：这不是任何平台会读取的地址。
我们帮客户排查二审时，约三分之一的案例最终归结为同一个问题：运营人员查了 ipconfig 看到 192.168，觉得「地址没毛病」，实际上平台读取的出口地址是本地电信宽带，根本没走代理。这种认知偏差多发生在第一次接触代理的团队，或从国内电商转跨境电商的运营身上——他们在国内平台习惯了看内网地址做网络诊断，直接把习惯带到了海外平台验收里。
公网 IP 才是平台读到的编号
平台读到的是你对外通信的公网 IP。未开代理时，这通常是你本地宽带运营商（如中国电信、联通、移动）分配给你的公网地址；开启代理并正确接管浏览器流量后，这应当是代理节点分配给你的出口地址。可以把公网 IP 理解成互联网上的「门牌号」，而内网 IP 只是你家里的房间号。
查询公网 IP 的方法很多：在浏览器打开公开查询页、使用命令行 curl ifconfig.me、或在路由器管理页看 WAN 口地址。业务验收最常用的是浏览器查询页，因为它最接近平台视角。
这里有一个容易忽略的细节：同一台电脑、同一个宽带，用不同的查询方式可能得到不同的结果。比如你在命令行执行 curl ifconfig.me 看到的是代理出口 IP，但在 Chrome 里打开查询页看到的却是本地 IP——这是因为终端走了代理而浏览器没走。我们建议始终以「实际登录平台用的那个浏览器」为准，因为平台也是通过浏览器/App 的 HTTP 请求读取你的 IP。
代理出口是怎么被分配的
代理服务商通常有一个地址资源池。你连接代理时，服务商会从池子里分配一个节点给你作为出口。这个节点可以是动态轮换的（每次连接或按周期更换），也可以是静态固定的（长期使用同一个 IP）。无论哪种，你都需要在「实际登录平台的环境」里确认这个出口是否真的被使用了。
经 NAT（网络地址转换）后，多台内网设备可能共用同一个公网 IP 出口。这也是为什么平台会把 IP 当作环境指纹之一：同一公网 IP 下如果多个账号行为相似，很容易被关联。
我们见过一个典型翻车案例：团队三个人共用一个办公室宽带，每个人配了独立的代理账号，看起来各走各的出口。但其中一个人代理没配好，浏览器实际走了办公室公网 IP。平台看到的是：同一公网出口下，同时登录了三个卖家账号。结果三个账号全部触发关联审核。这个案例说明一个简单道理：你看到的代理配置不等于平台看到的出口，必须以实际查询结果为准。
这 4 种情况，开号前必须重新查
代理环境一变，验收就要重做。以下四种情况，都应在登录平台之前完成地址查询，而不是事后补救。我们把这四种场景和对应的查法、判定标准、常见踩坑整理成一张表，方便你按自己当前的状态对号入座。
| 场景 | 建议查法 | 怎么算能用 | 容易踩的坑 |
|---|---|---|---|
| 新购代理试连 | 浏览器查出口（开代理前后各一次） | 第二次 IP 与代理宣称一致，且国家正确 | 只看代理客户端状态，不在浏览器里复验 |
| 指纹环境开号前 | 指纹浏览器配置页 + 浏览器查出口 | 环境绑定代理的出口 = 查询页结果 | 用办公室 Chrome 代替指纹 Profile 查 |
| 换节点 / 换供应商后 | 浏览器查出口 | IP 已变且符合目标国 | 客户端切换后浏览器会话仍缓存旧连接 |
| 封号复盘 | 浏览器 + 命令行交叉核对 | 确认当时实际出口，排除代理未生效 | 凭记忆判断，没有当时的 IP 记录 |
新购代理试连
销售发来截图不等于你的环境已生效。配好代理后，在实际用来登录的浏览器里查出口，别只在代理客户端界面看「已连接」。我的标准动作是：先关代理查一次（记 A），再开代理查一次（记 B），然后对比 A 和 B。如果 A 和 B 一样，说明代理没接管；如果 B 的国家不对，说明配置有误。
很多代理服务商会提供测试节点或试用额度，这一步尤其关键。我们见过有团队试用了三家代理供应商，对比了价格、速度和客服响应，最后选了一家——但试用的全程都没在浏览器里查过出口。接入后才发现该供应商在目标国家（比如德国）的节点池很小，实际分配到的 IP 经常被标记为机房而非住宅。这种情况如果在试连阶段就做了浏览器出口查验，一开始就能发现。
对于刚接触代理 IP 的团队，我们建议把「浏览器查出口」作为采购决策的硬性指标之一。不要只看控制面板上的在线率、延迟数字，那些数据在供应商那边可以优化展示，但你在浏览器里查到的出口 IP 不会骗人。
指纹环境开号前
多店团队常用 AdsPower、比特浏览器等工具隔离环境。每个 Profile 绑定的代理出口可能不同，要在该 Profile 内查，不能用办公室 Chrome 的结果代替。一个 Profile 里代理生效，不代表另一个 Profile 也生效。
我们在帮客户排查多店关联时发现一个高频错误：运营人员在一个 Profile 里配好代理并确认生效后，以为其他 Profile「应该也配好了」，直接批量开号。实际上每个 Profile 的代理配置是独立的——可能第二个 Profile 的端口号填错了，可能第三个根本没绑代理。建议每个 Profile 开号前都单独查一次，不要偷懒。5 个 Profile 就查 5 次，花不了三分钟，但能避免一个月的二审等待。
换节点 / 换供应商后
换 IP 后必须重新查。有些客户端「切换节点」后，浏览器会话仍缓存旧连接，查一次最稳。如果是换供应商，建议前三步（地址、属地、检测）全部重做，因为不同供应商的地址资源池质量差异很大。
具体来说，换了新供应商后至少确认三件事：出口 IP 国家是否正确、IP 类型是否是住宅（而非机房）、是否存在 DNS 或 WebRTC 泄露。有些供应商宣称提供「美国住宅 IP」，但实际分配的是租用数据中心的 IP 段，这些 IP 在平台的检测库里往往标记为 hosting/proxy，比真正的住宅 IP 更容易触发风控。
封号复盘
复盘时要还原「当时平台看到的 IP 是什么」。如果记录显示代理未生效或仍是国内出口，那封号就不意外。建议平时维护一个 IP 变更日志，至少记录：时间、账号、Profile、代理节点、查询 IP、查询国家、ISP、检测评分。封号后 24 小时内核对这份日志，能大幅缩短排查时间。
我们自己的运营团队强制要求每个账号维护这样的日志。不一定是复杂的系统——一个共享表格就够了。每换一次节点、每新增一个账号、每次开号前验收，都往表格里追加一行。这份日志的价值在封号复盘时体现得最明显：你能快速排除「是不是 IP 的问题」，把精力集中在其他可能的触发因素上（产品 listing 违规、Review 异常、支付信息变更等）。
浏览器、命令行、指纹，三种查法
按角色和目的选方法，不必三种全做，业务验收以浏览器/指纹环境出口为准。下面详细拆解每种方法适合什么人、在什么场景下用、以及最容易出错的环节。
浏览器查出口（适合业务方）
在要用来登录的浏览器里打开公开 IP 查询页，直接看当前出口地址和基础信息。最快、最贴近平台视角，出海团队首选。具体怎么选查询站，可以看 查出口和查质量，别混用一个网站，查出口和查质量别混用一个站。
浏览器查出口之所以是首选，核心原因在于：Amazon、TikTok、eBay 这些平台读取你的 IP 时，走的是 HTTP/HTTPS 协议，跟你用浏览器访问查询页的路径完全一致。你在浏览器里看到的出口 IP，就是平台看到的 IP。相比之下，命令行工具可能走了不同的网络栈（比如终端配置了独立的代理环境变量），代理客户端的「已连接」状态更是只反映了客户端的本地状态，不反映浏览器的实际流量路径。
操作上建议养成固定习惯：用同一个查询站、同一个浏览器、同一个步骤。这样当你发现某次结果异常时，至少能排除「查询站差异」或「浏览器差异」这两个变量。
命令行查本机（适合技术排查）
Windows 可用 ipconfig、Mac 可用 ifconfig 或 networksetup 查看本机网卡配置，主要用于区分内网地址和排查网络问题，不能替代查出口。如果想用命令行查公网，可以执行 curl ifconfig.me 或 curl icanhazip.com，但注意这取决于当前终端是否走了代理。
命令行方法更适合技术人员在自动化脚本里集成。比如你可以在部署代理后写一个简单的验收脚本：curl -s ifconfig.me | grep -q '预期IP段' && echo 'OK' || echo 'FAIL'。但业务方验收不建议只依赖命令行，因为终端代理配置和浏览器代理配置可能走不同的通道。
指纹浏览器内查（适合多店）
在 AdsPower、比特浏览器等工具的 Profile 配置页，通常可查看当前绑定代理的出口信息。多店运营应以 Profile 内结果为准，并与浏览器查询页交叉确认。如果两者不一致，优先信浏览器查询页，因为那是平台视角。
一个容易被忽略的点：部分指纹浏览器在 Profile 配置页显示的 IP 是「代理连接测试」的结果，这个测试可能用的是 ICMP ping 或简单的 TCP 连接，不等于浏览器 HTTP 请求实际走的出口。因此 Profile 配置页的数据只能作为参考，最终验收仍然要在 Profile 内打开浏览器访问查询页。
需要逐步命令？电脑端 IP 查询 覆盖 ipconfig、终端命令和代理未生效 3 个排查点；手机开号看 手机端 IP 验收，确认移动代理有没有真接管流量。
FAQ：常见问题
Q1：ipconfig 显示的是内网还是公网？
通常是内网。ipconfig 显示的是本机网卡从路由器获取的地址，常见 192.168.x.x。公网 IP 需要在浏览器查询页或路由器 WAN 口查看。如果你不确定当前看到的是什么类型，记住一个简单判断：以 192.168、10.、172.16-31 开头的都是内网地址，平台看不到。
Q2：为什么代理客户端显示已连接，但浏览器 IP 还是国内？
大概率是代理没接管浏览器流量。可能原因：分流规则 excludes 了目标域名、指纹浏览器 Profile 未绑定代理、全局代理模式未开启、或者本地网络优先走了直连。排查方法：换浏览器、换全局模式、检查 Profile 代理配置。我们自己的经验是，这个问题 80% 的情况是因为「系统代理」开关没打开——客户端显示已连接只代表隧道建好了，不代表系统已经把浏览器的流量路由进隧道。
Q3：手机代理 App 里显示已连接，但 Safari 查还是国内，怎么办？
检查 App 是否开启「全局代理」或「强制所有流量走代理」。很多 App 默认是「智能分流」或「仅代理部分应用」，Amazon / TikTok 的流量可能不在代理范围内。具体排查见 移动端查出口。
Q4：命令行查到的 IP 和浏览器查到的 IP 不一样，信哪个？
业务验收信浏览器。命令行可能没走代理，或者走了不同的网络接口。平台视角就是浏览器视角。如果你在排查网络问题，两个结果不一样反而是线索——说明终端和浏览器走了不同的网络路径，可以帮助定位代理配置的问题。
Q5：地址查对了，下一步做什么？
下一步是 IP 位置查询，确认出口国家在目标市场；然后做 开号前 IP 检测，过住宅、黑名单、DNS/WebRTC 泄露三关。
Q6：为什么我的代理 IP 查出来显示是机房而不是住宅？
部分代理供应商会把数据中心 IP 包装成住宅 IP 出售。判断方法：在 IP 查询页看 ISP 字段，如果显示的是 AWS、Google Cloud、DigitalOcean 等云服务商，大概率是机房 IP。真正的住宅 IP 通常会显示本地宽带运营商名称，如 Comcast、AT&T、Vodafone 等。如果你需要确保是住宅出口，建议选用明确标注「住宅代理」的服务，并在购买前要求提供测试节点进行浏览器查验。
延伸推荐
如果你刚确认自己查的是公网出口，下一步建议去做 出口归属地确认，确认国家 / ISP 是否符合目标市场。如果你还在选代理线路，可以先了解 IPWeb 的 按流量计费的动态住宅代理 和 固定家宽IP的静态住宅代理，分别适合多账号轮换和长期店铺养成。
关于 ipconfig 的用法，可参考微软官方文档 Apple 支持。
