查询页显示的是哪一层的 IP？
打开 IP 查询 页面时，你看到的是本次请求对该服务可见的出口地址。服务若使用可信反向代理，通常还会按自身配置解析转发的客户端地址。它不一定等于电脑网卡的地址：家庭 IPv4 网络通常经过网络地址转换（NAT），上游还可能存在另一层 NAT、代理或 VPN。应把“终端地址”“路由器 WAN 地址”和“网页观察值”分别记录，而不是把它们统称为自己的公网 IP。
代理和 VPN 是否改变网页出口，要看具体路由与分流规则。浏览器代理可能只转发网页请求，系统 VPN 也可能仅承载企业内部网段；全隧道配置才会把相应互联网流量送往 VPN 网关。因此，同一设备的不同应用、IPv4 和 IPv6 连接可能走不同出口。单凭网页查询不能确定地址由谁分配、是否独享，或设备是否使用了 VPN，必须结合当时实际生效的网络配置判断。
私有或共享地址通常应在本地网卡、光猫或路由器 WAN 状态里查找。正常公共互联网查询不应把 RFC 1918 或 RFC 6598 地址当作全球可路由的客户端出口；若页面显示这类值，应先核实是否为本地信息或转发配置问题。地址是否公网与信誉也不同：可路由地址可能有滥用记录，私有地址并不能直接参与公共信誉比较。具体可参考 IP 纯净度报告怎么读。
设备、路由器与运营商：四层地址关系
先按四个位置理解地址。第一层是终端在局域网使用的地址，例如 192.168.50.8；第二层是家用路由器的 WAN 接口，它可能拿到公网地址，也可能拿到上级光猫分配的私有地址；第三层是运营商网络，在 CGNAT 部署中，用户侧地址经过运营商转换后由公网地址对外通信，用户侧可能采用 100.64.0.0/10；第四层是目标服务观察到的请求来源。若还经过代理，目标看到的就是代理出口。
下面是一个明确标记为示意的家庭双重 NAT 案例。假设某用户家中的光猫由运营商配置为路由模式，光猫的 LAN 地址是 192.168.1.1，运营商为其 WAN 接口分配了公网 IP 203.0.113.10（示意地址，非真实用户地址）。用户又连接了一台无线路由器，该路由器 WAN 口从光猫获取 192.168.1.100，LAN 地址是 192.168.50.1。用户手机获得的地址是 192.168.50.8。手机访问 IP 查询网站时，数据包先由无线路由器把源地址改为 192.168.1.100，再由光猫改成 203.0.113.10，最终服务器看到的是 203.0.113.10。用户手机本地看到的局域网 IP 是 192.168.50.8，路由器后台看到的 WAN IP 是 192.168.1.100，两者都不是公网地址，但最终出口是公网地址。这个案例仅用于说明地址转换顺序，不代表任何实际用户环境。
如果路由器 WAN 是 100.64.0.2，而网页出口是另一个全球可路由 IPv4，这与上游地址转换相符，但仍需结合运营商说明确认具体架构。WAN 是 192.168.1.2 时，可能是光猫路由模式、第二台路由器或企业上级网关；这个数值本身不能告诉你是哪台设备做了 NAT。记录拓扑和各接口角色，比只截取一个地址更有助于排查。
精确识别私有地址和共享地址空间
RFC 1918 定义三个私有 IPv4 范围：10.0.0.0/8，即 10.0.0.0 至 10.255.255.255；172.16.0.0/12，即 172.16.0.0 至 172.31.255.255；192.168.0.0/16，即 192.168.0.0 至 192.168.255.255。所有 10 开头的 IPv4 都在第一段内，但不能把所有 172 或 192 开头的地址都当作私有地址。不在这三段内也不自动代表可在公网使用，还应核对其他特殊用途地址范围。
RFC 6598 定义共享地址空间 100.64.0.0/10，范围为 100.64.0.0 至 100.127.255.255，用于服务提供商网络内的特定场景，不属于全球可路由地址。路由器 WAN 落在这一范围是上游共享网络的重要线索，但不能单独证明运营商一定实施了哪一种 CGNAT。反过来，没有看到这个范围也不能排除上游 NAT，运营商的内部地址规划可能不同。
判断时必须按完整范围比较，不能把所有 100 开头的地址都标成 CGNAT。共享地址通常位于转换前的一侧，公共查询看到的是转换后的全球可路由出口，两者不是互相矛盾的结果。再确认查询是否经过代理、是否使用同一个 WAN 和地址族。只有把这些条件固定下来，地址差异才能成为有解释力的线索；最终套餐是否提供直接分配的公网 IPv4，仍以运营商确认和实际网络配置为准。
如何对照 WAN 地址与网页出口
尽量在同一时间、同一终端和同一网络下记录网页出口 IPv4，再核对实际承载该请求的路由器 WAN IPv4。重新拨号、切换 Wi-Fi、使用双 WAN 或代理分流都会影响比较。IPv6 的核对方法不同：终端通常拥有自己的全球 IPv6 地址，不能要求它与路由器 WAN IPv6 相等。应核实终端本次使用的源地址、运营商委派前缀和预期路由，临时 IPv6 地址也可能随时间改变。
在家庭网络中，优先查看状态页和现有拓扑，不必为了查看地址恢复设备出厂设置。企业或校园网络的用户可以把终端查询结果交给网络管理员，由管理员核对出口和上游转换。若设备有多个接口，要标明接口名称和作用，区分光猫管理地址、路由器 LAN 地址、WAN 地址和 VPN 虚拟接口地址，否则几个正确的数值放在一起也可能得出错误结论。
在同一 IPv4 请求、没有代理且选对 WAN 的条件下，WAN 与网页出口相同，通常不支持“这条路径还经过改变源 IPv4 的额外 CGNAT”这一推断。但地址相同不保证静态分配、独享或允许入站连接，运营商策略与主机、路由器防火墙仍可能限制访问。入站能力要从独立外部网络测试自己管理的服务，并分别记录协议、端口及失败阶段。
WAN 与出口不同，还有哪些原因？
WAN 地址与网页出口不同，首先考虑实际拓扑。光猫处于路由模式时，下级路由器可能从它取得私有地址，形成双重 NAT；系统 VPN 也可能让网页通过远端网关访问互联网。先确认光猫工作模式、VPN 分流和实际承载请求的接口，再判断差异来自哪一层。桥接、拨号或隧道设置的变更应按网络需求由运营商或管理员确认，不能仅为让两个数字相同就调整连接方式。
浏览器代理也会改变网页出口，而同一设备的其他应用可能直连。无痕窗口通常不会绕过系统代理，也不能保证禁用全部扩展；用于对照的浏览器配置必须确认代理和扩展状态。企业安全网关、远程浏览服务及多出口调度也可能造成差异。对于受管理的设备，直接请管理员核对策略，通常比自行关闭企业隧道更有效。
按层排除需要顺序进行。先确认设备上没有启用 VPN 或代理，再检查路由器 WAN 地址是否在 RFC 1918 或 RFC 6598 范围内。如果 WAN 是私有地址，则光猫可能仍是路由模式；如果 WAN 是 100.64.x.x，则运营商可能使用了 CGNAT；如果 WAN 是公网地址但网页出口不同，则可能有代理或企业网关。不要只凭一次截图就下结论，因为地址可能动态变化，代理软件也可能随系统启动。保持记录多个时间点的观察结果，并对照网络拓扑变化，才能提高判断准确性。
IPv4 与 IPv6 要分别验证
IPv4 和 IPv6 通常并行部署，却有各自的地址分配、路由和防火墙策略。终端可能通过 NAT 使用 IPv4，同时直接获得全球 IPv6 地址。IPv6 访问成功只说明这次 IPv6 路径和服务可用；IPv4 访问失败还可能涉及 DNS、路由、代理或服务端监听。CGNAT 对未建立映射的 IPv4 入站连接尤为相关，不能用它解释所有 IPv4 出站故障。
浏览器环境检测 可以辅助观察请求出口和浏览器网络行为，但不能据此证明外部主机能主动连接你的 IPv6 服务。入站验证要有实际监听的服务、相应防火墙规则，以及来自独立外部网络的测试。两种协议的允许规则可能不同，因此“网页能连接”和“别人能连入”应分开验收，不能只凭页面显示全球 IPv6 地址就声称入站开放。
排查时分别记录 IPv4、IPv6 的目标、源地址与失败阶段。若怀疑路径不符合代理或 VPN 预期，可阅读 WebRTC、DNS、IPv6 泄漏排查。WebRTC 候选反映浏览器可收集的接口或出口线索；DNS 测试通常观察测试查询到达权威服务器时的递归解析器来源，不是把域名解析得到的目标 IP 当作你的出口。关闭 IPv6 可能掩盖现象，应先明确具体是哪一条路径不符合预期。
端口映射失败怎么分析
端口映射失败时，先确认本地服务正在运行，并监听预期的接口和端口。若只绑定 127.0.0.1 或 ::1，外部设备无法直接连接；可以根据服务需要绑定指定内网接口，并配合主机防火墙限制访问。把服务改成监听所有接口不是唯一办法，还可能扩大暴露范围。先从局域网另一台设备验证应用响应，再逐层排查路由器与上游网络。
如果本地监听与主机防火墙都正常，下一步检查路由器上的端口转发规则。常见的错误包括：转发到了错误的内部 IP、内外端口不匹配，或者协议选成了 TCP 而实际服务使用 UDP。有些路由器还需要在防火墙上单独放行该端口，并重启使规则生效。此时可以在内网的另一台机器上测试服务是否可达，以隔离路由器配置问题。
路由器配置正确却仍无法入站时，再比较 WAN IPv4 与网页出口，并核实上游 NAT 和运营商政策。TCP 连接检测 可在工具允许的公网目标与端口范围内提供外部观测；若输入被工具策略拒绝，这不是目标连接失败的证据。TCP 测试也不能代替 UDP 服务的验证。外部测试失败要保留原始原因，不能统称为 CGNAT。
如果外部测试显示端口不可达，还需要考虑运营商是否对常用的入站端口，如 80、25、445 等，进行了封锁。有些运营商默认阻止所有入站连接，除非用户申请公网 IP 或特定端口放行。此时应联系运营商确认政策，而不是反复修改本地配置。排查顺序可以整理为：本地监听、主机防火墙、路由器转发、上游 NAT、运营商限制，每一步只改变一个变量，才能准确判断问题所在。
共享出口如何影响验证码与 IP 信誉
使用共享出口 IP 时，其他用户的行为可能影响该地址的声誉，从而触发更多验证码或访问限制。需要区分地址级观测和具体使用者。地址级观测只能说明某个 IP 曾经出现过自动请求或异常流量，并不能确定是谁发出的，也不能证明当前使用者有恶意。运营商 CGNAT 下可能数百甚至更多用户共享同一个 IPv4 地址，任何一个人的异常都可能被网站记录到该地址。
Google 的 异常流量帮助 说明，共享网络或 VPN 中其他用户的自动查询可能触发异常流量提示。这是可能原因，不代表能据提示确定是哪位用户或哪个程序发出了请求，也不能断言该出口进入了某个公开黑名单。应保留具体错误和出现时间，并按 验证码与黑名单排查 分别核对网络、浏览器和目标网站规则。
共享 IP 本身不意味着不安全，也不代表用户有恶意。很多机构通过 CGNAT 节省 IPv4 地址，是正常的网络工程实践。安全评估应基于具体流量和会话，而不是一个共享地址。如果因验证码问题联系网站或运营商，可以说明自己处于共享出口环境，并提供可观测的访问时间与行为证据，而不是要求对方将整个 IP 洗白，因为洗白可能掩盖真实异常。
对于网站运营者来说，依赖单个 IP 的信誉进行判定容易造成误伤。更合理的做法是结合用户代理、TLS 指纹、行为模式等多种信号，并对共享出口用户提供额外的验证方式，例如邮件或短信验证码。普通用户遇到验证码增多时，可以尝试更换网络环境，或向网站反馈出口 IP 段与访问时段，但不要使用规避工具绕过访问控制。
给运营商的工单写什么
向运营商提交工单时，信息越完整，处理速度越快。需要提供准确的时区与时间，例如 UTC+8 下的具体日期和时间段，便于运营商匹配日志。同时贴上路由器 WAN 接口显示的 IP 地址，如果路由器 WAN 不是公网地址，也要如实填写。外部观测到的出口 IP 可以通过查询网站获取，两者并列可以快速判断是否存在中间 NAT。
如果同时使用 IPv4 和 IPv6，必须分别说明。很多移动网络或家庭宽带已启用 IPv6，但 IPv4 仍可能经过 CGNAT。描述问题时不要只说“无法访问”，而要给出需要的入站协议，例如 TCP 443 端口用于 HTTPS，或 UDP 51820 端口用于 WireGuard。同时描述现有拓扑，例如光猫桥接还是路由模式、路由器品牌与型号、是否经过二级路由。
工单中不应要求运营商将 IP 从黑名单中“洗白”，除非有具体证据表明该地址被错误标记。更合适的问法是：当前套餐是否提供公网 IPv4 地址？是否允许入站连接？如果 IPv4 不可用，是否提供 IPv6 入站？这些问题直接关系到网络能力，而不是信誉。敏感日志，如完整流量记录或访问凭证，不需要主动提供，但如果运营商需要进一步排查，可按最小必要原则提供脱敏日志。
如果运营商要求提供证据，可以整理一个时间线：何时配置了端口映射、从哪个外部网络测试、使用了什么测试工具、得到什么结果。这些证据应保持原样，不要修改截图或输出。工单跟进时，记录每次沟通的时间、客服编号和结论，便于形成可复查的记录。清楚地写出期望的解决方式和下一步时间点，也能提高处理效率。
家庭用户与开发者分别怎么选
家庭用户需要远程访问自己管理的设备时，可先确认套餐是否支持公网 IPv4 或 IPv6 入站，再选择适合的方案。若没有直接入站能力，可评估经过认证的反向隧道或中继服务，核实访问控制、维护方式、费用和可用性，并遵守所在网络的管理规则。是否需要这种方案取决于业务目标，不必把“必须有公网 IPv4”当作所有远程访问的前提。
对于公网 IP 与端口可达性，家庭用户常有一个误区：认为只要路由器 WAN 地址是公网地址，所有端口就能从互联网访问。实际上，许多家用宽带即使分配了公网 IPv4，也会在运营商边缘设备上阻止常见服务端口。而且动态公网 IP 可能变化，远程访问还需要配合动态 DNS。如果只是为了临时访问，使用厂商提供的远程管理或授权的中继服务更稳妥。
开发者做互联网服务联调时，不能把本机外网访问成功当作互联网入站验收。本机通过 NAT 或防火墙出站访问成功，只说明出站路径通畅，并不代表外部可以主动连接到本机。例如一个 Web 服务在 localhost 上运行，通过 curl 访问外部 API 成功，不能证明外部用户能访问该 Web 服务。需要从另一台位于不同网络的机器，或使用外部 TCP 检测工具进行主动测试。
开发者还应核对容器、虚拟机及宿主机之间的端口发布。容器内服务正常，不等于宿主机已经在预期接口开放该端口；宿主机回环地址可访问，也不代表局域网或互联网可访问。最终验收应写明观察点和应用结果：TCP 服务需要完成连接及预期交互，UDP 服务需要发送符合协议的请求并检查响应，不能用没有连接握手的 UDP 得出“TCP 已建立”式结论。
三个常见问答
公网 IP 是固定的吗？这取决于运营商和套餐。家庭宽带通常使用动态地址，即使分配了公网 IPv4，也可能在租约到期、重新拨号或设备重启后改变。企业专线或固定 IP 套餐可以提供静态地址，但需要额外付费。IPv6 地址通常由前缀委派，如果运营商前缀不变，设备地址可能在一段时间内稳定，但也不保证永久不变。不要假设地址固定，远程服务仍需动态 DNS 或定期更新配置。
重启路由器一定换地址吗？不一定。地址变化取决于 DHCP 租约时长、运营商地址池策略和认证方式。有时重启后地址不变，有时会变化，没有普遍规律。在 CGNAT 环境下，重启可能改变的是运营商内部映射关系，而不是公网出口地址。如果需要确定当前出口是否变化，可以在重启前后使用多个独立的查询服务记录出口 IP，并注意时区与网络环境不变。
多个用户共用公网 IP，不自动意味着他们可以互相访问，也不构成安全隔离的证明。实际隔离依赖接入网络配置、访问控制与设备防火墙，不能把 NAT 当作完整安全边界。共享出口可能产生信誉关联，使正常用户一起遇到验证码或限制，但具体影响取决于目标网站策略。应分别评估连通性、地址信誉和设备安全，避免用一个“共享”标签概括全部问题。
形成可复查的记录
在排查公网 IP 与端口可达性问题时，记录应能支撑事后复查。创建时间线时，采用示意方式：例如某日 10:00 配置路由器端口转发，10:05 从外部网络使用 TCP 检测工具测试 8443 端口失败；10:10 修改主机防火墙，10:15 再次测试仍失败。这样的记录能清晰展示每一步行动与结果。不要省略失败的操作，因为失败同样能排除变量。
每次只改变一个变量并记录前后结果，同时调整防火墙和路由器规则会让原因难以判断。可保存状态页、错误文本、测试时间及出口结果；对外提供材料时移除账号、令牌等无关信息。理解地址类型、来源和观测边界，可阅读本站 方法论。记录的重点是让下一位排查者能够复现条件，而不是堆积无法解释的截图。
共享 IP 或代理检测可能产生误判，例如正常家庭网络因共享出口被标记为 VPN 或代理。此时应收集出口 IP、查询时间和检测平台，记录多个平台的判定差异。不要仅依赖一家黑名单或检测服务，有些平台对 CGNAT 网段不友好。相关误判案例与排查方向见 VPN 代理检测误判，其中说明了如何辨别地址级标记与实际代理行为。
当排查记录足够完整但仍无法解决问题时，应设定明确的停止条件。例如：已经修改本地监听与防火墙、确认路由器规则正确、从两个不同外部网络测试均失败，且运营商回复无入站能力。此时下一步应该是向运营商申请公网地址或采用授权的中继方案，而不是继续猜测或修改。结束后将全部记录归档，标注结论为“无法建立入站连接，原因指向运营商策略”，并附上证据链。
