什么是 ERR_TUNNEL_连接_失败了吗？

Scrapeless Proxies 通过有文档记录的网关路由客户端请求，以实现基于代理的网页采集。

ERR_TUNNEL_连接FAILED 表示 Chromium 无法通过代理为所请求的连接建立隧道。对于通过 HTTP 代理发起的 HTTPS 请求，请检查 CONNECT 交换及其响应。该消息标识的是隧道失败所处的阶段；它本身并不能区分身份验证问题、目标限制以及上游连接问题。

CONNECT 交换创建隧道

隧道使客户端能够通过 HTTP 代理承载另一种协议。对于通过 HTTP 代理进行的普通 HTTPS，客户端首先请求代理与目标 authority 建立连接。在收到成功的隧道响应后，客户端可以通过该连接交换目标 TLS 字节。

请提供需要翻译的英文文本。 HTTP CONNECT 方法规范 定义了成功切换到隧道模式。代理的响应属于隧道建立阶段的交换内容。它与目标服务器稍后可能在加密连接内发送的 HTTP 响应是分开的。将这两种响应区分开来，是诊断该错误的第一步。

即使浏览器已经连接到会说代理协议的服务，也可能发生隧道失败。该服务可能会拒绝目标地址、要求进行身份验证，或未能创建后续连接。浏览器通常只会显示一个顶层的失败字符串，而不是完整且便于运维人员理解的说明。请保留客户端或网关提供的所有协商细节。

The Chromium 隧道错误定义 标识无法建立的隧道。它不应被理解为对目标完全宕机的诊断。记录网关、请求的目标主机和端口，以及最后一次观察到的隧道响应或事件。这些字段比页面上显示的消息更准确地定位边界。

区分 CONNECT 响应与目标响应

在代理调查中，由哪个环节返回响应决定了某个 HTTP 状态码的含义。对 CONNECT 的响应来自代理交换，而目标 TLS 之后的应用响应则属于目标端请求路径。否则，相同的数字类别可能会导致错误的事件负责人。

如果代理请求身份验证，请检查代理质询和受支持的凭据配置。如果它拒绝目标，请检查网关的目标和端口策略。如果网关无法获得后续连接，它自己的日志中可能包含浏览器未暴露的 DNS、路由或侦听器详细信息。

The Chromium HTTP 代理套接字实现 这说明了为何隧道建立有其独立的响应处理。身份验证响应和不受支持的隧道响应可以走不同的路径。避免使用过度简化的规则，即认为每个非成功响应在任何上下文中都会产生完全相同的浏览器代码。

不要因为收集方需要目标的状态就丢弃 CONNECT 响应。应为代理协商和目标响应分别保留字段。如果隧道从未打开，目标响应应保持为空，而不是把代理的状态当作网站返回的内容填进去。

网关协议和目标端口是两个独立的选项

代理连接需要使用网关所记录的传输方式和协议。目标方案不会自动选择代理方案。HTTP 代理可以通过建立隧道来承载 HTTPS，而与网关建立 TLS 连接则是另一种配置选择。

同时检查客户端配置和所支持的代理协议。错误的网关方案会阻止有意义的 CONNECT 交换。仅仅因为都用于转发流量，SOCKS 监听器并不能与 HTTP 代理监听器互换。请使用客户端和服务提供方所支持的、完全匹配的代理类型。

目标端口可能会被代理策略限制。一个运行在常用安全端口上的公共 HTTPS 网站可能可以访问，而运行在自定义端口上的应用程序则可能被拒绝。因此，一个可用的控制目标只表明有一个被允许的隧道存在，而不是对所有主机的访问权限。当请求诊断时，请向网关所有者提供目标主机名和端口。

当前 无抓取代理端点和凭据配置 是频道设置的权威来源。复制受支持的端点值和频道生成的凭据结构。这在不声称任何特定目标必须可达的前提下，为调查建立一个已知的配置。

在不混淆各层的情况下测试隧道阶段

受控隧道调查会保持客户端、网关和身份验证配置不变。将已授权的公共 HTTPS 控制目标与受影响的目标进行比较。记录每个目标的 CONNECT 交换结果。如果控制隧道能够建立，那么针对受影响主机，仍然可以将特定目标的策略或后续连通性视为一个有价值的假设。

纯 HTTP 控制请求可以测试转发行为，但不会建立 HTTPS 隧道。如果 HTTP 转发正常而 HTTPS 隧道失败，应检查 CONNECT 支持、隧道建立过程中的身份验证处理以及目标策略。避免仅凭这种对比就得出目标上的所有证书都无效的结论。

当控制端和目标端在隧道建立阶段都失败时，应先检查共享配置，而不是直接排查目标页面逻辑。检查所选代理、凭据来源和协议。如果客户端与服务提供方的设置一致，则收集协商过程的证据用于支持排查。不要通过更改 HTML 选择器或调整渲染等待时间来弥补尚未确认的隧道问题。

一旦某个隧道建立成功，就将该阶段标记为完成，并独立检查下一阶段。此时目标可能在 TLS 身份验证、安全协商或其应用请求上失败。后续阶段的失败并不意味着之前的隧道从未建立。捕获记录应保留这一顺序。

隧道故障与类似错误的比较

阶段区分比一个通用的浏览器修复列表更有用。其中每一个观察都指向了不同的首要证据集。

网关连接失败发生在 HTTP 代理交换之前。代理身份验证要求标识出发出响应的身份验证边界。隧道建立失败将注意力引向 CONNECT 协商。隧道打开后出现的证书问题与正在被验证的安全端点的身份和信任有关。

某些客户端工具会将这些错误包装在更广泛的请求异常中。请使用它们文档中提供的诊断字段，并保留原始的基础事件。你的规范化作业类别可以写成“代理隧道不可用”，但不要虚构目标 HTTP 响应或确认的网络原因。

当隧道无法打开时保护捕获身份

不成功的隧道未能提供所请求的目标表示。收集器应创建一个网络诊断事件，并保持源内容未被接收。代理错误页面（如果有）属于代理交换，而不是目标站点的文章或产品页面。

当所需的隧道失败时，请不要在未告知的情况下悄然选择不同的路由。路由更改可能会改变特定地区的定价、内容可用性和身份验证行为。只有在明确允许并记录的情况下，可控的备用路由才是有用的；而隐形的路由替代会使生成的数据集更难以解读。

将网关详细信息与机密凭据值分离。保留提供方端点、已清理的通道引用、请求的权限以及响应类别。在导出跟踪之前，编辑掉授权头和敏感的 URL 参数。网关运营方需要足够的信息来找到这次交互，而不是用于授权它的密码。

The HTTPS 隧道与 TLS 检查对比 解释了一个相关的边界：隧道可以传输加密流量，而其本身并不是解密服务。 无爬取代理产品 提供路由基础设施，而 当前代理方案 帮助评估流量需求。无论是计划还是 IP 变更都无法修复目标的证书或登录逻辑。

有用的隧道分辨率应当是什么样子

一个有用的解决方案会同时说明 CONNECT 的结果，以及改变该结果的配置或策略修正。如果网关按设计拒绝了某个目标，那么路由审批应由策略所有者负责。如果凭证提供错误，就应纠正客户端的认证路径。如果后续连接失败，则应利用网关端的证据来定位故障位置。

隧道打开后，在接受捕获之前完成 TLS 和内容验证。这是比让浏览器停止显示 ERR_ 更严格的完成标准。隧道_连接失败。它表明预期的来源是通过所需路径到达的。