浏览器工作流中的 IPv4 与 IPv6 代理一致性
了解双栈地址选择如何与代理路由和 DNS 配合，并用受控检查维护稳定的浏览器网络策略。
双栈网络可以通过 IPv4 或 IPv6 访问服务，但地址族只是路由的一部分。浏览器可能把请求交给代理，让代理解析目标域名，也可能先解析代理主机名，或让代理未承载的能力使用其他路径。稳定的工作流需要明确规定传输、名称解析和失败处理。
一致性不要求每条连接使用相同地址族，而是要求连接遵循已声明的网络边界。IPv4 目标和 IPv6 目标都可以通过同一获准代理策略访问。代理失败后静默改为直连属于另一种策略，应向用户显示失败，而不应伪装成成功。
网络策略应当无需抓取底层数据也能理解。支持人员需要知道预期路由、解析器归属、支持的网络条件和用户可见的失败行为。更详细的网络记录只用于获准支持案例中的有限升级，而不是常规遥测。
双栈网络中的地址选择
应用通常从主机名开始，而不是从 IP 地址开始。DNS 可以返回 IPv4 和 IPv6 候选项，客户端再决定先尝试哪一个。RFC 6724 第 6 节将目标地址选择定义为依据指定规则对候选地址排序。结果取决于可用地址、主机路由表、配置策略和实际可达性。DNS 返回的地址只是候选项，不代表路径一定可用。
RFC 8305 第 5 节描述了 Happy Eyeballs 的连接尝试顺序，以保持双栈连接建立的响应性。客户端先尝试一个候选项，再经过有限延迟启动另一个；某次连接成功后，应取消尚未成功的尝试。这有助于在某个地址族缓慢或不可达时更快恢复。不同网络或路由更新后的胜出地址族可能不同，因此不应把它保存为永久的 profile 数据。
代理会改变地址选择发生的位置。浏览器把主机名交给代理时，代理可以从自身网络解析目标。客户端先解析并提交地址时，本地环境参与目标选择。代理主机名本身也可能要在隧道建立前由本地解析。HTTP CONNECT 的请求目标标识目标主机和端口，成功后接收方会建立隧道并双向转发数据（RFC 9110 第 9.3.6 节）。SOCKS5 请求可使用 ATYP DOMAINNAME 将完整域名作为目标地址传给服务器（RFC 1928 第 4、5 节）。这些属于不同的归属模型，配置应明确说明采用哪一种，而不能只凭“使用代理”推断所有 DNS 行为。
地址族也不能直接等同于位置或身份。IPv4 与 IPv6 是传输选择，任何一方都不能单独证明用户的物理位置、网络提供方或预期地区。支持记录可以保存预期路由标签和本次观察到的地址族，但不应把一次连接选择变成对个人或设备的长期描述。
连接复用会让地址族选择看起来比实际更稳定。浏览器可以继续使用已经建立的连接，因此后续多次导航沿用第一次连接的地址族。新 context、空闲连接关闭或网络切换都可能重新触发选择。长会话若依赖稳定路由，应分别比较新连接与复用连接，并记录浏览器是否刚启动、context 是否新建以及请求是否复用了现有连接。
代理与 DNS 的归属
网络策略应以归属来描述。明确谁解析代理主机名、谁解析目标主机名、代理承载哪些流量，以及路径不可用时浏览器如何处理。使用获准地区路由的团队可以让代理端解析页面目标，使请求和 DNS 留在同一受管边界。另一种部署也可以先使用组织解析器，再连接固定代理地址。只要决策清楚并经过验证，两种方式都可能有效。
本地解析不一定意味着隐私问题，远程解析也不一定意味着完整保护。结果取决于各解析器看到的数据、运营方和路由是否符合用户预期。即使页面内容已加密，解析流量仍可能暴露访问的主机名。解析器边界应与代理策略记录在一起，同时避免为了确认解析器工作而永久保存用户的目标历史。
浏览器可能使用多个网络子系统。普通 HTTP 请求、实时通信、扩展流量、更新服务和操作系统请求可以采用不同控制。页面代理设置不应被描述为整台机器所有进程的保证。代理、DNS 与 WebRTC 一致性指南说明这些表面的关系，DNS 隐私检查则集中讨论解析器边界。
代理认证和端点详情应存放在受保护配置中，而不是写入测试输出或公开材料。验证记录通常只需要路由名称、地址族结果、浏览器版本和通过状态，不需要完整代理 URL 或凭据。连接详情只供维护路由的操作人员访问，支持导出默认应遮蔽这些值。
解析缓存也需要明确归属。浏览器、操作系统、代理和解析器都可能按照各自实现和 DNS 数据保存结果。因此策略更新后，旧答案或旧连接可能暂时存在。不要把清理所有缓存作为第一反应，因为那会破坏判断答案来自哪一层的证据。先在现有 context 中复现，再与受控的新 context 比较，并根据结果决定活动会话是否可以结束当前任务或必须重新启动。如果两个 context 都返回旧结果，应先检查权威 DNS 记录和解析器路径，再考虑修改浏览器 profile 设置。
路由发生分歧的常见原因
双栈代理主机名可以同时解析为两个地址族，但代理服务在某个客户端网络上可能只接受其中一种。客户端会先等待不可达候选项，再尝试可用候选项。陈旧 DNS 答案、不一致的负载均衡或防火墙规则也会产生相似症状。判断重点应是已声明的代理端点是否到达，而不是上一次会话使用了哪个地址族。
目标解析也可能在不同边界产生差异。本地解析器和代理侧解析器可能因为地理位置、分区 DNS、企业策略或记录传播而收到不同答案。浏览器因此可能到达不同服务版本。只比较自有或获准测试的域名，并在记录中包含解析器位置和测试时间，不要从一个差异推导所有主机名的行为。
回退行为最容易制造严重不一致。库可能在代理请求失败后直接重试，扩展可能建立自己的连接，service worker 也可能继续使用旧策略下建立的连接。页面看似可用时，声明边界可能已经失效。获准路由不可用时，应显示明确错误并让用户决定是否重试。若路由变化会混合不同网络策略下的状态，应启动新的浏览器 context。
协议支持还会带来另一层差异。承载普通网页请求的代理不一定承载页面使用的每种数据报或实时传输。禁用不受支持的可选路径、选择已有说明的兼容路径，或报告功能不可用，都比静默直连更清楚。工作流依赖普通导航之外的能力时，可参阅网络层浏览器一致性。
受控验证方案
使用自有端点验证策略。准备 IPv4-only 端点、在环境支持时准备 IPv6-only 端点，并准备双栈端点。端点只需返回收到请求的服务地址和简短、不含敏感信息的测试请求 ID。不要把无关 header、凭据或完整客户端地址写入长期日志。端点响应、预期路由标签或观察到的地址族，单独都不能证明请求经过了哪个代理。
在不改变 profile、代理策略、DNS 策略和应用构建的情况下，对每个端点执行相同浏览器任务。记录哪个端点完成以及是否向用户显示回退。只有测试配置能让两侧观察到同一请求 ID 时，才能直接匹配它；HTTPS 代理隧道通常看不到加密流量内部的 ID。否则，应对受控的单个请求，按时间、目标和连接标识关联独立的连接或出口证据。无法明确关联时，标记代理使用情况未验证。如果双栈端点采用了与上次不同的地址族，应先检查可达性与路由策略，而不是直接判定回归。当前网络条件下的选择可能完全有效。
在合成基线中，声明受管代理路由仅支持 IPv4 目标，并且只有一个获批的 IPv4 出口。IPv4-only 和双栈测试端点都应通过该路由完成；须独立关联代理连接证据，并确认自有端点观察到的源地址与获批出口一致。IPv6-only 端点应报告路由不可用，并保留输入，不得重试直连；若请求经其他出口完成，则违反策略；缺少关联证据时，代理使用情况仍属未验证。
应分别测试代理主机名解析与目标解析。代理主机名失败属于路由设置问题，代理连接后发生的目标解析失败属于另一个阶段。分开阶段可以避免支持人员在真正问题是解析器、防火墙或代理服务时去修改无关 profile 设置，也能在不暴露连接详情的情况下保存有用记录。
验证还要包括中断与恢复。在受控任务期间断开获准路由，确认浏览器不会继续直连；恢复路由后，按照应用策略要求用户主动重试或新建 context。确认原始用户输入仍可使用，且部分提交不会被显示为完成。这些检查关注应用行为，不评价地址信誉或第三方服务的决策。
下载和上传应使用单独的测试样例，因为它们可能比启动任务的导航持续更久。使用小型合成文件，在传输开始、进行中和主动中断后检查路由。应用要区分完整文件、可恢复的部分文件和失败传输。重试必须保持同一声明路由，或要求用户在新 context 中重新开始，不应静默组合来自不同策略的片段。上传完成得到确认前，保留本地源文件，不记录上传内容；下载应核对最终大小与应用显示的状态，且不要超出支持事项所需时间保留目标地址。
处理网络与平台差异
有些客户端网络提供原生 IPv6，有些使用地址转换，有些只有 IPv4。企业 VPN、移动网络、家庭路由器和云主机可以在浏览器未变化时呈现不同组合。产品应定义支持的网络条件。如果 IPv6 是可选项，应用应能在声明的 IPv4 路由上工作。如果部署要求 IPv6-only，就应在该条件下验证代理和解析器，而不是假定双栈行为足够。
网络切换需要明确策略。笔记本可能在浏览器 context 保持打开时从办公 Wi-Fi 切换到移动网络。现有连接可能继续，新连接可能选择另一地址族，代理主机名也可能得到不同答案。需要稳定路由的工作流应暂停任务，让用户重新连接或创建新 context。混合切换前后的状态会让原本有效的会话难以解释。
受管系统可以在浏览器之外设置 DNS、VPN 或代理策略。浏览器设置应与这些控制一起审查，而不是假设能够覆盖它们。记录哪一层具有权威性以及由哪个团队维护。浏览器更新若与操作系统或网络策略变化同时发生，应固定其他变量后再复现用户任务。
错误信息应说明失败阶段并给出安全的下一动作。“代理不可用”“无法解析目标名称”和“IPv6 路由不可用”需要不同检查。笼统的连接失败会促使用户反复重试或临时修改配置。清晰信息也能减少收集包含无关浏览与网络数据的大型诊断包。
浏览器 context 打开期间，名称解析仍可能变化。DNS 记录会过期，受管解析器会更新策略，代理服务也会迁移端点。长时间运行的工作流应规定下一条连接是否接受变化，或要求受控重启。涉及敏感提交的任务可以在路由身份变化时停止，普通内容阅读则可能接受同一策略所有者下的重新连接。记录路由标签和用户可见中断即可，不需要永久保存每个解析地址。
网络状态也要满足可访问性要求。路由失败不能只通过颜色或短暂提示表达。操作无法继续时，应把焦点移到简洁状态信息，保留表单输入，并提供一个明确的重试或重启动作。若应用支持离线工作，应说明哪些操作留在本地、哪些需要受管路由。键盘和屏幕阅读器用户也应能区分暂停、失败和完成。
持续维护策略
为支持的浏览器构建和网络条件保留小型发布矩阵。记录可以包含浏览器版本、操作系统族、路由标签、解析器归属、端点类型、观察到的地址族和功能结果。使用合成请求，并在审查期后删除临时日志。矩阵应回答声明路径是否工作，而不是建立用户访问过的每个网络的历史 profile。
代理提供方、解析器、浏览器版本、操作系统或部署网络变化时都应复查策略。验证完整用户任务，而不只检查 socket 能否连接。页面连接成功时，认证、下载、实时能力或长请求仍可能采用不同路径。可选能力只有在相同边界下通过验证后才应启用。
支持收到不一致结果时，先从路由标签和失败阶段开始。确认代理端点是否解析、连接是否建立、目标解析是否完成，以及自有端点是否收到请求。只有较小记录无法解释问题时，才通过获准支持渠道请求完整连接详情，并在案例结束后删除敏感材料。
依赖稳定路由的用户需要看见策略变化。如果发布改变了支持的网络条件，应说明受影响的工作流、可用回退以及是否需要新的浏览器 context。不要把传输地址族变化写成普遍平台结论。明确的路由策略、少量受控测试和清楚的失败行为，比强迫每条连接偏好同一地址族更可靠。
