查电脑代理出口就两步：关代理查一次、开代理查一次，对比 IP 变没变。但真正踩坑的人都知道，问题往往不在步骤本身，而在「以为自己查对了」。下面给 Windows / Mac / 指纹浏览器的完整实操流程，每一步都附上我们团队实际遇到过的翻车点和排查思路。

目录

开代理前后各查一次，别跳过

标准动作三条：关代理在浏览器查一次出口，开代理再查一次，两次 IP 对比——相同则说明代理没接管，别登录。命令只是手段，重点是确认代理真接管了流量。下面按 Windows、Mac、指纹浏览器分别走一遍。

为什么必须关代理先查一次？因为你需要一个基准线。如果你不知道自己的本地出口是什么，就没法判断代理是否真的改变了出口。我们见过有人直接开代理查了一次，看到 IP 是美国就以为没问题——但他不知道的是，他的本地宽带出口本来也是美国（因为他用的是美国云桌面），所以代理根本没生效。没有「关代理查一次」做对比，就无法识别这种情况。

关代理和开代理，出口差多少

状态 出口 IP 国家 ISP 判定
代理关闭 58.xxx.xxx.xxx CN 中国电信 本机宽带
代理开启 73.xxx.xxx.xxx US Comcast Cable 代理生效 ✓

若两次 IP 相同，说明代理未生效，别登录 Amazon 或 TikTok。复盘里最常见的是：客户端显示「已连接」，系统代理没开，或分流把查询站走了直连，浏览器一查仍是本机宽带。IP 变了但国家不对，接着做 出口归属地确认。

这里补充一个我们实际遇到的边界情况：代理开了，两次 IP 也确实不同，但第二次查到的 IP 是香港而不是美国。客户买的明明是「美国代理」，为什么出口跑到了香港？原因是代理供应商在亚洲部署了中转节点，客户的流量先经过香港中转再到美国——但浏览器查出口时，由于查询站的 GeoIP 库版本问题，把中转 IP 误判为最终出口。这种情况要做更深层的 traceroute 或联系供应商确认路由。

Windows：ipconfig 和浏览器各查一遍

设置里看到的 IP 一般是内网

Win11：设置 → 网络和 Internet → 属性，可看到 IPv4 地址。注意：这里多为 RFC 1918 定义的 192.168 段内网地址，不是平台看到的公网出口。

我们帮客户远程排查时，经常遇到对方截图「设置」里的 IPv4 地址来问「这个 IP 是不是美国」。答案永远是：先确认你在看的是什么。Windows 设置里默认展示的是本地网卡的 IPv4，这个地址跟代理出口是两码事。

ipconfig 看网卡，不等于出口

按 Win+R，输入 cmd，回车后输入 ipconfig（命令说明见 Microsoft 文档）。找「以太网适配器」或「无线局域网适配器」下的 IPv4 地址。查本机网卡用这条；查出口请往下看浏览器方法。

进阶用法：ipconfig /all 可以看更详细的信息，包括 DHCP 服务器、DNS 服务器等。当你怀疑代理没生效是因为 DNS 泄露时，这个命令能帮你确认当前系统实际使用的 DNS 服务器是不是代理隧道里的。另一个常用命令 ipconfig /flushdns 可以清空 DNS 缓存，在切换代理后如果怀疑浏览器缓存了旧 DNS 记录，先执行这条再查出口。

浏览器里才是平台看到的 IP

在 Chrome/Edge 打开任意公开 IP 查询页，页面显示的就是当前浏览器流量的公网出口，这才是 Amazon Seller Central 等平台会看到的 IP。也可在终端执行 curl -4 ifconfig.me，返回单行公网 IPv4，适合脚本化验收。

一个实操细节：如果你用的是 Chrome，建议开一个无痕窗口来查出口。原因有两个：一是无痕窗口不会加载已安装的扩展程序，排除了某些代理插件干扰结果的可能性；二是无痕窗口不继承登录态和 Cookie，更接近平台首次访问时的视角。我们团队的标准 SOP 就是「无痕窗口 + 关代理查一次 + 开代理查一次」，三步走完再登录平台。

Mac：终端和浏览器两种查法

系统设置只能看本机

系统设置 → 网络 → 已连接的网络 → 详细信息，可查看本机 IP 与路由器信息。同样，此处多为内网地址，不能替代出口查询。

Mac 用户特别容易混淆的一个地方是「网络」面板里的「代理」标签页。这个标签页显示的是系统级代理配置（SOCKS/HTTP 代理），但它只是配置界面，不表示代理当前是否真正在转发流量。即使这里填了正确的代理地址和端口，如果代理客户端没有在运行，浏览器流量仍然走本地。判断代理是否生效的唯一标准是浏览器查询页的结果。

终端 ifconfig / curl ifconfig.me

打开「终端」，输入 ifconfig（Mac 终端基础见 Apple 终端手册）查看各网卡地址；查公网出口输入 curl -4 ifconfig.me 更直接。

Mac 上 ifconfig 的输出比 Windows ipconfig 更丰富，会列出所有网络接口——包括虚拟网卡、VPN 隧道、代理创建的 utun 接口等。当代理客户端运行后，通常会多出一个 utun 接口，这是代理创建的虚拟网络层。看到这个接口说明代理在系统层面建立了隧道，但浏览器流量是否走了这条隧道，仍然要查出口才能确认。我们遇过代理客户端创建了 utun 接口但路由表没更新，导致流量绕过隧道直连的情况。

在登录用的浏览器里查

与 Windows 相同：在 Safari/Chrome 打开 IP 查询页，开代理前后各查一次。多店团队用指纹浏览器时，务必在对应环境内的浏览器查，不要用系统浏览器代替。

Safari 用户额外注意：macOS 上 Safari 的代理行为可能与 Chrome 不同。部分代理客户端默认只接管 Chrome 流量，Safari 走的是系统 WebKit 网络栈，可能绕过了代理。如果你用 Safari 作为主力浏览器，务必在 Safari 里查出口，不要用 Chrome 代替。我们建议 Safari 用户优先确认代理客户端支持「系统全局代理」模式，确保所有浏览器的流量都被接管。

AdsPower / 比特浏览器里出口在哪看

代理配置页 + 环境内浏览器

AdsPower、比特浏览器等工具的环境配置页通常有「代理设置」区域，把代理的主机、端口填进去后，在该环境的内置浏览器打开 IP 查询页，确认出口与配置一致。我去年给深圳客户配 AdsPower 时，ipconfig 显示正常，但环境内查出口仍是深圳电信——系统代理开了，指纹浏览器却走独立通道，没绑上节点。

那次排查花了我们整整一个下午。最后发现是 AdsPower 的代理设置里有一个「使用系统代理」的开关，客户以为打开了就行，但实际上这个开关只对部分内核版本生效，他用的那个内核版本需要手动在「自定义代理」里填入 SOCKS5 地址。问题解决后，我们给所有客户的指纹浏览器环境都加了同一个验收步骤：每新建一个 Profile，先在环境内浏览器查出口，确认国家正确再往下走。

另一个常见问题是代理协议的选择。SOCKS5 和 HTTP 代理在指纹浏览器里的行为有差异：SOCKS5 支持 UDP，HTTP 代理不支持。如果你的业务涉及 WebRTC 或实时通信，建议优先用 SOCKS5，并在验收时额外检查 WebRTC 是否泄露了真实 IP。可以找一个 WebRTC 泄露检测站，在指纹浏览器环境内跑一次。

如果你需要长期固定一个 IP 做店铺养成，IPWeb 的 适合长期开号的静态住宅出口 配合指纹浏览器使用，能保持环境稳定性。多账号高频轮换的场景则可以搭配 按流量计费的动态住宅代理，每个 Profile 绑定不同出口。需要独享带宽的还可以考虑 独享数据中心静态IP，适合对延迟敏感的业务场景。

查出来还是本机 IP？先查这 3 处

ipconfig 正常但浏览器查出口仍是国内宽带？按下面顺序排查：

系统代理没真开

代理客户端显示「已连接」，但「系统代理」或「TUN 模式」未启用，浏览器流量仍走本地宽带。检查客户端设置，确保系统级代理已开启。

如何判断系统代理是否真的开了？Windows 用户可以打开「设置 → 网络和 Internet → 代理」，看「使用代理服务器」是否处于开启状态，以及地址和端口是否与代理客户端一致。Mac 用户可以在「系统设置 → 网络 → 高级 → 代理」里查看。如果这里显示的是空白或不匹配，说明客户端虽然显示已连接，但并没有修改系统的代理设置。

查错浏览器了

部分浏览器插件、独立 Chromium 内核可能绕过系统代理。在实际用来登录平台的那个浏览器里查出口，不要用另一个浏览器代替。

具体来说：如果你平时用 Chrome 登录 Amazon Seller Central，就用 Chrome 查出口；如果你用 Edge 登录，就用 Edge 查。不同浏览器对系统代理的遵循程度不同，Firefox 甚至可以配置独立的代理设置而不使用系统代理。多浏览器环境下，每个浏览器都要单独验收。

分流规则把查询站直连了

代理客户端的分流规则可能把国内站点或特定域名设为「直连」。IP 查询站若在直连列表里，查到的仍是本机 IP。临时关闭分流或把查询站走代理通道再测。

排查方法：在代理客户端的「分流规则」或「路由规则」里搜索你用的查询站域名（比如 whatismyipaddress.com、ipinfo.io 等），看是否被匹配到了「直连」或「DIRECT」规则。如果是，将其改为「代理」或「PROXY」再测。我们建议至少准备两个不同的查询站，交叉验证可以更快排除「查询站被直连」这种问题。

FAQ：常见问题

Q1：电脑关了代理再查，为什么还是显示美国？

可能是浏览器缓存了代理会话，或者你用的是指纹浏览器 Profile 没切换。建议关闭浏览器重新打开，或在无痕模式下再查一次。如果无痕模式仍然是美国，检查是否有系统级的 VPN 或其他代理软件在后台运行——Windows 上可以在「网络和 Internet → 代理」里确认，Mac 上在「系统设置 → 网络 → VPN 与过滤器」里查看。

Q2：ipconfig 显示 192.168，那我的代理生效了吗？

ipconfig 显示的是内网地址，平台看不到。必须去浏览器查询页看公网出口，才能确认代理是否生效。192.168 这个地址段专门用于局域网，任何平台服务器都无法通过互联网路由到这个地址——所以平台不可能读取你的 192.168 地址来判断你的位置。

Q3：AdsPower 里怎么看代理有没有连上？

AdsPower 在 Profile 配置页通常会显示代理 IP，也可以在 Profile 内打开浏览器访问 IP 查询页交叉确认。我们建议以 Profile 内浏览器查询页的结果为准，配置页显示的 IP 仅作参考。如果两者不一致，优先排查代理协议（SOCKS5 vs HTTP）和 Profile 的网络设置。

Q4：Mac 和 Windows 查出来的 IP 会不一样吗？

如果连接的是同一个代理节点，公网 IP 应该一致。如果不同，说明代理没有全局接管，或者不同设备走了不同出口。我们建议多设备团队统一验收标准：每台设备、每个浏览器都单独做「关代理 + 开代理」对比，确保所有设备查到的出口 IP 一致。

Q5：电脑查完了，手机还要查吗？

必须查。电脑和手机是两套环境，同一个代理账号在不同设备上的出口也可能不同。特别是做 TikTok 运营的团队，手机端的代理配置和电脑端往往不同，不能互相替代验收。手机端的具体方法见 手机端 IP 验收。

Q6：curl ifconfig.me 查到的 IP 和浏览器不一样，以哪个为准？

以浏览器为准。curl 走的是终端网络栈，浏览器走的是浏览器网络栈。代理客户端可能只配置了浏览器代理（通过 PAC 或插件），而终端没有走代理。如果你需要命令行也走代理，需要设置环境变量 http_proxy 和 https_proxy，或者在代理客户端里开启「全局/TUN 模式」。

延伸推荐

电脑出口查完后，建议按顺序继续：IP 归属地查询 确认国家/ISP，再做 登录前的 IP 检测 过三关。还没确定代理方案的，可以先了解 内网 IP 和代理出口的区别，搞清基本概念再动手配代理。