文章目录

引言：你能从本指南获得什么

如果你在使用移动代理，迟早会在采集器日志、指纹浏览器控制台或广告后台窗口中看到类似「407 Proxy Authentication Required」「502 Bad Gateway」「504 Gateway Timeout」或简短吓人的「tunnel failed」这样的字样。此时，代理服务器错误就像一个黑匣子：不清楚是代理本身的问题、你的软件的问题、目标网站的问题，还是仅仅密码过期了。本指南将黑匣子变成清晰的行动方案。

我们有意限定范围：只讲解代理层返回的错误码和消息。连接级别的网络超时（完全无响应、由客户端自行终止等待）在博客中另有文章详解，这里不再赘述。如果你日志里出现的是具体错误码或关于 tunnel 的提示，那你看对文章了。

最终你能收获什么

  • 理解这四种错误各自的含义，以及它们分别诞生在「你的软件—代理—目标网站」链条的哪个环节。
  • 学会在两三分钟内用任何系统自带的 curl 工具定位问题源头。
  • 获得应对 407、502、504 和 tunnel failed 的完整操作流程，可以当成清单逐项执行。
  • 让你的软件对每种错误码做出正确反应：有的错误需要重试，有的重试毫无意义。
  • 建立个人故障日志，下次出问题时能节省数小时。

适合谁阅读

本指南面向营销人员、联盟营销从业者、小型团队负责人和开发者，他们使用移动代理，但不一定是网络工程师。主体内容针对新手：每条命令都有解释，每个操作都有步骤。对于自己写脚本、想更深入的人，文末有专门的进阶板块。

需要提前掌握的知识

只要会打开终端或命令提示符、往里粘贴文字并能看懂结果就够了。了解什么是 IP 地址和端口会有帮助，我们也会简要提醒。不需要编程经验。

预计耗时

通读全文并完成第一次排查需要 60 到 120 分钟。如果你现在正遇到某个具体错误，直接跳到对应步骤即可：处理每一种错误，加上检查，大概需要 15-25 分钟。

准备工作：工具和权限

排查代理层错误不需要安装大型软件，几乎所有工具你的操作系统里都有。不过还是提前准备一下，免得故障发生时到处找密码、想不起配置文件在哪。

必需工具

  1. 终端或命令提示符。Windows 10 和 11 中，打开「开始」菜单，输入「cmd」或「PowerShell」，回车。macOS 中打开「应用程序」，再打开「实用工具」，然后打开「终端」。Linux 中终端通常用 Ctrl+Alt+T 调出。
  2. curl 工具。Windows 从 10 版本（1803 构建）起自带，macOS 和大多数 Linux 发行版也自带。验证方法：在终端输入 curl --version 并回车。应该出现版本信息行，例如「curl 8.x.x」。如果提示找不到命令，用你的系统的包管理器安装 curl。
  3. 普通浏览器，带开发者工具。任何现代浏览器都行，按 F12 打开面板，切到「Network」（网络）标签。
  4. 文本编辑器，用来记录故障日志。记事本也行，但带语法高亮的更舒服，能看清日志结构。
  5. 你的工作软件：指纹浏览器、采集器、广告账号管理器或自己的脚本。我们需要能访问它的代理设置和日志。

必需的访问权限

  • 登录代理服务商的后台。对 mobileproxy.space 用户来说，就是管理渠道的页面，能看到主机、端口、用户名、密码、认证类型以及换 IP 链接。
  • 至少一个代理的当前凭据：地址（主机）、端口、用户名和密码，或用于 IP 认证的已确认 IP。
  • 了解你用的是哪种协议：HTTP(S) 代理还是 SOCKS5。这个信息后台也能看到。

系统要求

过去八年内发布的任何操作系统都行。能访问代理主机的网络连接。其他什么都不需要。

备份

在修改工作软件的代理设置之前，先保存当前状态。五分钟就能搞定，能避免「你治好了错误，同时也弄丢了十个账号的可用配置」这种局面。

  1. 在指纹浏览器里，导出配置文件列表及其代理设置。导出功能通常在配置文件菜单里，会生成 CSV 或 JSON 文件。
  2. 在采集器或脚本里，把配置文件复制到另一个文件夹，文件名带日期，例如「config_backup_2026-03-14」。
  3. 从后台把所有渠道的凭据复制到文本文件。把这个文件放在别人无权访问的地方。
  4. 记下你电脑或服务器当前的 IP。如果你用 IP 地址认证，会用到它。

建议：建一个名为「代理日志」的文本文件，每次错误都按「日期、时间、错误码、代理主机、目标网站、我做了什么、什么起了作用」的格式记录。一个月后你就有了个人知识库，比任何文章都管用。

检查：终端能打开，curl 命令能显示版本，你已经登录后台并看到至少一个代理的凭据，配置备份放在单独文件夹里。可以继续了。

基础概念：代理层的结构和错误码的来源

要想有逻辑地修复代理服务器错误，而不是靠瞎试，就得理解请求的路径。它由三段组成，我们的四个错误分别出在不同的段上。

请求路径的三段

  • 客户端—代理。你的浏览器、采集器或脚本连接到代理的主机和端口。这一段检查认证。407 错误和部分 tunnel failed 就诞生在这里。
  • 代理—移动网络—目标网站。代理服务器收到你的请求后，以自己的名义通过带运营商 SIM 卡的调制解调器连接到目标网站。502 和 504 在这里出现。
  • 目标网站—回程。网站的响应沿同样的节点返回。如果网站返回了自己的错误码，比如 403 或 429，那已经不是代理层的错误了，学会区分它们很重要。

用大白话说错误码的分类

响应码是服务器在响应第一行发送的三位数字。第一位代表类别。4xx 表示「问题在你这边，改改请求」。5xx 表示「问题在服务器或其后端」。对代理层来说是这样：

  • 407 Proxy Authentication Required — 代理说：「我不知道你是谁，或者你的数据不对」。4xx 类别：要在自己这边修。
  • 502 Bad Gateway — 代理说：「我试着往下游连了，但收到的是断开或乱码，不是响应」。5xx 类别：问题在代理之后或代理本身。
  • 504 Gateway Timeout — 代理说：「我等下一跳的响应等到超时了」。同样是 5xx。

504 和网络超时有什么区别

这是全文最关键的一个区分。当你看到错误码 504，说明代理服务器活着，接收了你的请求，自己等待了网站响应，然后自己把失败告诉你。你和代理之间的连接此时工作得完美无缺。而当你的客户端写「connection timed out」或「operation timed out」且没有错误码时，说明根本没收到响应，断开是你的软件自己发起的。前者是本文的主题，后者是另一篇文章的内容，详见博客相关材料。简单的判断方法：响应里有三位数字——继续往下读这里。

什么是隧道，为什么会「失败」

当你通过 HTTP 代理打开 HTTPS 网站时，浏览器先向代理发送特殊的 CONNECT 命令，带上目的地址和端口。代理与网站建立连接，并回应「200 Connection established」。之后通过代理传输的是加密流，代理本身不再读取。这种连接就叫隧道。如果代理对 CONNECT 命令的回应不是 200，客户端就会写「tunnel failed」，旁边通常还会注明收到的是哪个错误码。所以 tunnel failed 不是独立的错误，而是某个错误码的外壳。

两种认证方式

  • 用户名和密码。客户端在 Proxy-Authorization 请求头里传递。最常见的方式，也是 407 最常见的来源。
  • 按 IP 认证。你提前在后台登记自己电脑或服务器的地址，代理就会放行来自该地址的所有请求，无需密码。方便，但你的 IP 一变就会失效。

能看出响应作者的服务头

代理通常会在响应里加上 Via、Proxy-Agent 或 X-Proxy 请求头。目标网站不会设置它们。如果带 502 的响应里有 Proxy-Agent，你就确切知道是代理回的。如果没有这些头，而有 Server 加上网站服务器名称，那就是网站本身的响应。我们会积极利用这个特征。

建议：记住一条口诀：「四开头找自己，五开头找代理后面，隧道先看旁边的数字」。这一条能解决一半的情况，不用再往下读。

第 1 步：确定到底是谁返回了错误

本阶段目标：在几分钟内准确判断是代理服务器、目标网站还是你自己的软件回了你，并记录完整的响应文本用于后续工作。

操作步骤

  1. 打开后台，复制出问题代理的凭据：主机、端口、用户名、密码。举例我们假设主机是 proxy.example.net，端口 8080，用户名 user1，密码 pass1。请替换成你的值。
  2. 打开终端。
  3. 输入命令，替换凭据和目标地址，回车：curl -v -x http://user1:pass1@proxy.example.net:8080 https://example.com/。参数 -v 开启详细输出，-x 指定代理。
  4. 等命令执行完。通常一到三秒。如果命令「挂」了超过 30 秒，按 Ctrl+C：多半是网络超时而不是错误码，不是本文主题。
  5. 在输出里找以「>」开头的行（curl 发送的内容）和以「<」开头的行（收到的响应）。响应的第一行会是类似「HTTP/1.1 407 Proxy Authentication Required」或「HTTP/1.1 200 Connection established」。
  6. 看标有 CONNECT 的那一行。如果紧随其后收到的是非 200 的错误码，说明错误是代理在隧道阶段返回的。如果 CONNECT 得到 200，而错误码出现在 TLS 握手相关行之后，那返回的就是目标网站了。
  7. 查找响应头。有 Proxy-Agent、Via 之类的服务头，就明确是代理。有 Server 加网站服务器名、有 Set-Cookie，就指向目标网站。
  8. 把同一条命令去掉 -x 参数再跑一遍，也就是直连：curl -v https://example.com/。如果网站返回 200，而通过代理返回 5xx，问题就定位在代理之后的环节。
  9. 再通过代理访问另一个网站，比如任何一个稳定的大型资源。如果第二个网站能打开，问题跟具体目标有关，而不是代理整体。
  10. 把完整输出连同日期时间复制进代理日志。后续步骤会用到它。

通过浏览器的替代方法

如果不方便用终端，打开已配置代理的浏览器，按 F12，切到「Network」标签，勾选「Preserve log」（保留日志），刷新页面。在请求列表里找红色错误码那一行，点击它，在「Headers」标签里看「Response Headers」区块。逻辑一样：找代理的服务头。这个方法的缺点在于浏览器经常隐藏 CONNECT 阶段的细节，所以对 tunnel failed 来说终端更合适。

注意：带 -v 参数的命令会把代理用户名和密码以明文输出。不要把这份输出贴进公共聊天、工单或截图，除非把密码替换成星号。

建议：给命令加上 -sS 和 -o 指向空设备，避免响应体刷屏：curl -sS -v -o /dev/null -x http://user1:pass1@proxy.example.net:8080 https://example.com/。Windows 下用 NUL 代替 /dev/null。

预期结果

日志里出现了带完整响应的记录，你能有把握地说出以下三种之一：「代理在认证阶段返回的」「代理在访问网站阶段返回的」或「网站自己返回的」。这会把你引向第 2 步、第 3-4 步，或者超出本文范围。

可能遇到的问题

  • 命令提示「Could not resolve proxy」。主机拼错了。逐字符对照后台核对。
  • 命令提示「Failed to connect to proxy」。端口关闭或不对。这是传输问题，不是错误码，检查端口并换个渠道试试。
  • 输出在 TLS 行处断开且无错误码。说明隧道建立了，但网站没在你的客户端超时内响应。别和 504 搞混：没有错误码，就不是本文的情况。

检查：你能说出响应的作者和确切的错误码或短语，且 curl 输出行已保存在日志里。

第 2 步：解决 407 Proxy Authentication Required 错误

本阶段目标：让代理对 CONNECT 命令回应「200 Connection established」而不是 407，并搞清原因，避免错误再次出现。

为什么会出现 407

代理没有接受你的凭据。原因通常有六种，我们按由易到难依次检查：拼写错误、密码含特殊字符、按地址认证时 IP 变动、渠道过期、软件根本没传数据、浏览器缓存了旧数据。

操作步骤

  1. 打开后台，找到出问题的渠道。确认它没有过期且状态是活跃的。如果已过期，续费后一分钟再重试；这种情况不用往下走。
  2. 检查该渠道启用了哪种认证方式：用户名密码还是按 IP 地址。很多面板允许同时启用两种。
  3. 如果启用了按 IP 认证，查出你电脑或服务器当前的外网地址。用浏览器直连（不走代理）打开任何显示 IP 的服务，和后台登记的地址对比。家庭宽带和移动运营商会经常在重启路由器后改变地址。如果地址不一致，在后台更新它，等一两分钟：更改不会立即生效。
  4. 如果用的是用户名密码，从后台重新复制它们，不要手打。粘贴进第 1 步的 curl 命令里执行。一半的 407 问题到这里就结束了。
  5. 看看密码。如果里面有 @、:、/、#、?、% 或空格，在地址字符串里传递时需要对它们编码。@ 变成 %40，冒号变成 %3A，井号变成 %23，百分号变成 %25。例如密码 p@ss:1 在 URL 里写成 p%40ss%3A1。不想编码的话，用单独的参数传递：curl -v -x proxy.example.net:8080 --proxy-user user1:p@ss:1 https://example.com/。这里 curl 会自己处理特殊字符。
  6. 如果 curl 能通过，而你的工作软件仍然收到 407，问题出在软件本身。打开它的代理设置。确认用户名和密码填在单独的字段里，而不是如果程序不期望的话粘在地址上。检查密码末尾有没有空格：复制时经常会带上。
  7. 在指纹浏览器里打开特定配置文件的设置，而不是全局设置。很多用户改了代理总列表里的密码，但配置文件还存着旧副本。在配置文件里重新保存代理并重启配置文件。
  8. 如果浏览器记住了旧数据不询问新数据，在浏览器设置里清除该主机的已保存密码，或新建一个配置文件来测试。
  9. 注意 407 响应里的 Proxy-Authenticate 头。如果写的是「Basic」，说明代理期待常规的用户名密码对。如果写的是其他方案，你的软件必须支持它；对移动代理来说几乎总是 Basic，不一致就说明代理类型设置有误。
  10. 重跑 curl 请求，确认现在 CONNECT 返回 200。

注意：不要试图用批量重试来「解决」407。有些代理服务器在多次认证失败后会临时封禁地址，你会在原有问题之上再添一个。一次检查、一次修正、一次验证。

建议：如果你有几十个渠道，用表格管理，用户名和密码各占一列，旁边再有一列放已为 URL 编码好的密码。这样你永远不会搞错哪个版本该往哪儿放。

预期结果

curl 输出里 CONNECT 的响应行变成了「HTTP/1.1 200 Connection established」，网站返回了内容。工作软件里的请求也能通过。日志里写下了原因：拼写错误、编码、IP 变动、过期或缓存。

可能遇到的问题

  • 407 出现两次：先是在 CONNECT 上，然后在隧道内部。这是软件只在其中一个阶段发送数据的迹象。更新程序，或打开其中关于在 CONNECT 时传递认证的选项。
  • 后台说 IP 已添加，但 407 依旧。你可能在公司网络或有多出口的服务器上工作。要从实际发出请求的机器上检查地址。
  • 你这边能行，同事用同样数据不行。按 IP 认证时这是正常的：同事的地址不一样。改用用户名密码或添加第二个 IP。

检查：连续三次通过 curl 和工作软件的请求都没有 407，原因已记入日志。

第 3 步：处理代理返回的 502 Bad Gateway 错误

本阶段目标：区分换 IP 瞬间的短暂故障与方向或渠道的持续问题，并为每种情况选择正确的处理方式。

为什么代理会返回 502

代理接收了你的请求，试图往下游建立连接，结果遇到断开、拒绝或无法解析的响应。对移动代理来说，典型原因有：调制解调器此刻正在切换 IP 或在运营商网络里重新注册；目标网站重置了连接；代理端无法解析网站域名；渠道同时承载的流数过多而过载；网站对所有用户都不可用。

操作步骤

  1. 记录 502 出现的精确时间，精确到秒。下一步会用到。
  2. 在后台查看该渠道的换 IP 历史记录，或回想是否开启了按计划自动轮换。如果轮换和错误发生在同样的秒数，说明你遇到的是正常现象：在地址切换期间的两到十秒内，请求会收到 502。解决办法是暂停后重试。
  3. 等十秒，重跑第 1 步的 curl 命令。如果响应变成 200，在日志里写「轮换瞬间的 502」，然后去第 6 步配置重试。
  4. 如果 502 持续反复，用同一个代理访问另一个网站。能打开——问题在目标方向。打不开——问题在渠道。
  5. 针对目标方向的问题：不用代理直连目标网站。如果直连也不可访问或返回 5xx，跟代理无关：网站挂了。如果直连一切正常，网站可能在断开来自该运营商地址的连接。用后台的换 IP 链接更换 IP 后重试。如果无效，换另一个运营商或地区的渠道试试。
  6. 针对渠道的问题：在后台检查设备状态。很多服务商有调制解调器状态指示灯。红色或黄色表示渠道正在恢复，只能等或切换到备用渠道。
  7. 检查负载。看看你的软件里有多少并发流经过这个渠道。移动渠道带宽有限，几十个并发连接时，代理会正好以 502 开始拒绝部分请求。把并发数减半再测试。
  8. 检查是否和 DNS 有关。如果网站允许，改用 IP 地址访问而不是域名，或者切换到 socks5h 方案（由代理解析域名），对比结果。如果按域名 502 而按 IP 正常，就是代理端解析域名的问题；把确切的域名告诉服务商。
  9. 如果 15 分钟内都没解决，收集 curl -v 输出、时间、渠道主机、目标域名，发送给服务商支持。信息收集得好，解决时间能从一天缩短到一小时。

建议：使用按计划轮换时，提前把软件里的暂停和换 IP 间隔对齐。如果地址每 5 分钟变一次，就让采集器在每个五分钟开始的时刻暂停 15 秒。不用写一行复杂代码，502 的数量就能几乎降到零。

预期结果

你准确知道你的 502 属于哪一类：轮换瞬间、特定目标、渠道过载、设备故障或网站不可用。前三类你有修复方法，后两类你知道该等什么、该找谁。

可能遇到的问题

  • 只有下载大文件时才出现 502。网站因上传速度慢而关闭连接。减小请求数据的大小，或使用覆盖更好的渠道。
  • 502 是网站返回的，不是代理。检查响应头：如果有网站的 Server 而没有 Proxy-Agent，是网站内部故障，稍后重试。
  • 502 和 200 交替出现，看不出规律。典型的渠道过载迹象。降低并发直到结果稳定。

检查：通过问题渠道向稳定网站连发十次带两秒间隔的请求都返回 200，或者你手上已经有带完整数据的支持工单。

第 4 步：处理 504 Gateway Timeout 错误

本阶段目标：弄清代理解之后哪个环节在丢时间，把 504 的比例降到可接受水平，同时不把错误码和客户端网络超时搞混。

代理返回 504 到底意味着什么

代理服务器本身对网站响应有内部等待上限。当网站来不及在这个上限内响应时，代理就停止等待，并诚实地用 504 告诉你。此时你的客户端并没有断开连接，响应是收到了的。正因如此，你软件里的等待上限必须大于代理的上限：否则你只会看到没有错误码的网络超时，无法搞清楚怎么回事。

操作步骤

  1. 检查你软件里的等待上限。大多数程序里它叫 timeout、「响应等待时间」或「Read timeout」。如果小于 30 秒，暂时设为 60。这是诊断步骤：你需要等到代理返回的错误码。
  2. 测量通过代理的响应时间。执行：curl -sS -o /dev/null -w "%{http_code} %{time_connect} %{time_starttransfer} %{time_total}" -x http://user1:pass1@proxy.example.net:8080 https://example.com/。参数 -w 输出四个数字：错误码、连接耗时、首字节耗时和总耗时（秒）。
  3. 把同一条命令去掉 -x 参数执行。对比首字节时间。如果直连网站 0.4 秒响应，通过代理要 8 秒，说明「代理—网站」段延迟很大，移动网络一波动就会出现 504。
  4. 检查 504 出现在哪个请求上。用 HEAD 方法发起请求，它不加载页面正文：curl -I -x http://user1:pass1@proxy.example.net:8080 https://example.com/。如果 HEAD 能过而 GET 整页返回 504，问题在体积或页面生成慢，而不在连接本身。
  5. 用后台的换 IP 链接更换渠道 IP。移动网络不均衡：一个地址可能连到过载基站，另一个连到空闲的。重新测量。如果时间降到几倍以下，就在软件里加条规则：遇到 504 先换 IP 再重试。
  6. 检查目标页面的重量。有些网站要执行冗长的服务器操作后才返回响应。如果你的目标是具体数据，试试访问同站更轻的地址：API、移动版、不带排序参数的页面。
  7. 如果 504 只针对某个特定域名且只通过某个运营商的渠道出现，记入日志，把这个域名的工作转移到其他运营商的渠道上。
  8. 把软件里的等待上限调回工作值，但这次是有意识的：它应该略大于通过代理的典型响应时间，又小于你在任务中愿意等待的时间。对大多数场景来说是 30-45 秒。

注意：不要「以防万一」把软件等待上限设成几分钟，也不要长期保持那样。一个卡住的流会占住队列里的位置，十个卡住的流就会造成代理不工作的假象，而问题其实在一个慢网站上。

建议：在软件日志里加一列「首字节时间」。通过它能看出渠道是在逐渐退化还是突然崩掉。逐渐上升意味着过载或覆盖差，突然下降多半说明轮换或运营商故障。

预期结果

你知道通过每个渠道的典型响应时间，把软件里的上限设得比代理上限高，504 成为少见事件，并有自动应对。

可能遇到的问题

  • 你调高了上限，结果 504 变成了网络超时。说明代理等的比你想象的久，或者与代理的连接不稳定。这已经超出错误码范围，请看关于超时的相关材料。
  • 504 只出现在特定时段。移动网络晚高峰过载。把重活挪到夜间或清晨。
  • 第一次访问新网站时 504，之后都很快。代理端首次解析域名和建立连接。正式批量前加一次预热请求。

检查：对工作网站连发二十次请求，首字节时间在可预测范围内，504 不超过一两个，且软件遇到 504 会换 IP 并重试。

第 5 步：解决 tunnel failed 错误

本阶段目标：学会读懂 tunnel failed 旁边的数字，把它和真正的原因对应起来，并修正协议、端口和代理类型的设置。

长什么样，是什么意思

在 curl 里消息长这样：「CONNECT tunnel failed, response 407」。在浏览器和指纹浏览器解决方案里，可能是「Proxy tunnel failed」「Unable to establish tunnel」或「Tunnel connection failed」。共同点是：客户端发送了 CONNECT 命令，而代理回应不是 200。旁边的数字就是那个错误码，处理方法和前面几步一样，只是多几个仅在隧道阶段才出现的特殊情况。

操作步骤

  1. 用带 -v 参数的 curl 请求 HTTPS 地址，找到 tunnel failed 那一行。记下 response 后面的数字。
  2. 如果是 407，回到第 2 步。唯一区别：确认软件是在 CONNECT 阶段传递认证的。一些旧版程序里的「代理认证」勾选框只对 HTTP 请求生效，隧道则不带密码发出。
  3. 如果是 502 或 504，回到第 3 和第 4 步。代理无法建立与网站 443 端口的连接，或没等到它响应。
  4. 如果是 403，代理拒绝向指定端口或主机建立隧道。检查你连的是哪个端口。移动代理通常允许到 443 和几个常见端口的隧道。如果你的服务监听非标准端口，向后台或服务商确认是否允许。
  5. 如果是 400，代理看不懂命令。最常见的原因是你把 SOCKS5 代理当成 HTTP 配置，或反过来。打开后台看发给你的是哪种协议和端口。很多服务商给同一渠道的 HTTP 和 SOCKS5 用的是不同端口。
  6. 修正命令里的方案。对 SOCKS5 使用：curl -v -x socks5h://user1:pass1@proxy.example.net:1080 https://example.com/。socks5h 里的 h 表示由代理解析域名，而不是你的电脑。对移动代理来说这是首选方案。
  7. 如果在指纹浏览器里，打开配置文件的代理设置，找到类型下拉框：HTTP、HTTPS、SOCKS5。选后台标注的那个，并检查端口。保存后完全重启配置文件，而不是只刷新标签页。
  8. 如果 tunnel failed 旁边没有数字，只有短语，就在软件里打开扩展日志，或通过 curl 复现，以获得错误码。
  9. 检查你的软件是否试图与代理本身建立 TLS 连接。有些程序在选择「HTTPS」类型时不仅加密到网站的流量，还加密到代理的连接。如果代理不支持，你会得到 tunnel failed 或握手错误。切换到「HTTP」类型来连接代理：到网站的流量在隧道里依然是加密的。
  10. 重跑测试，确认 CONNECT 得到 200 且页面加载成功。

建议：把两个简短的测试请求纳入日常：一个通过 HTTP 访问某地址，另一个通过 HTTPS 访问同一地址。如果第一个能过第二个失败并报 tunnel failed，你就能立刻明白问题在隧道，而不在认证或渠道。

预期结果

tunnel failed 从日志里消失，每个渠道都记录了正确的类型和端口，软件里没有开启多余的到代理的加密。

可能遇到的问题

  • 隧道建立了，但随后报证书错误。这已经不是代理层了：是网站或你的系统证书集。检查电脑的日期和时间。
  • curl 能行，软件用同样数据不行。软件用了不同的方案或加了自己的前缀。查阅它关于代理字符串格式的文档。
  • tunnel failed 只针对一个网站。网站用了非标准端口，回到关于 403 的那一步。

检查：通过 curl 和工作软件的 HTTPS 请求都让 CONNECT 返回 200，所有渠道的类型和端口都记在表格里。

第 6 步：为每种错误码配置正确的软件反应

本阶段目标：让代理服务器错误自动处理：有的带暂停重试，有的立即报警，你看到的是清晰的日志，而不是一片红色错误行。

原则：不是所有错误都一样

遇到 407 重试毫无意义：密码不会因为重试就变对。遇到轮换瞬间的 502 必须重试：五秒后就正常了。遇到 504 最好换 IP 后重试。这三条规则构成了健康错误处理的基础。

现成软件的操作步骤

  1. 打开采集器或账号管理器的设置，找到负责重试的区块。它可能叫「Retries」「重试次数」「错误处理」。
  2. 把 5xx 的重试次数设为 3，初始间隔 5 秒并翻倍递增：5、10、20 秒。这种递增叫指数退避，不会让你的软件把已经过载的渠道彻底压垮。
  3. 如果软件允许指定重试的错误码列表，填 502 和 504。不要把 407 放进去。
  4. 找到 407 时的动作设置。如果没有，把总重试次数设为最小，并打开失败请求通知。你的目标是在头几分钟就看到 407，而不是停机一天后才发现。
  5. 如果有换 IP 链接的字段，填入后台对应渠道的链接，并开启「出错时换 IP」或「失败时轮换」选项。
  6. 限制单个移动渠道的并发流数。从 3-5 开始，逐步提高，直到 502 的比例低于百分之一。
  7. 打开详细日志，保存响应码和请求头。确认日志里能区分代理返回的码和网站返回的码：很多程序在单独的「Proxy status」列里显示。
  8. 保存设置，重启软件，跑 50 次请求的测试序列。

自己写脚本的操作步骤

如果你写代码，逻辑一样。用 Python 的 requests 库写伪代码大致是这样：

proxies = {"http": "socks5h://user1:pass1@proxy.example.net:1080", "https": "socks5h://user1:pass1@proxy.example.net:1080"} for attempt in range(3): r = session.get(url, proxies=proxies, timeout=45) if r.status_code == 407: alert("auth failed") break if r.status_code in (502, 504): rotate_ip() sleep(5 * 2 ** attempt) continue break

注意三点。第一：遇到 407 我们立即跳出循环并发送通知。第二：遇到 502 和 504 先换 IP，再等待递增的暂停。第三：timeout 值选得能等到代理返回错误码，而不是提前断开。

注意：有些库在 CONNECT 阶段的错误不是以带错误码的响应形式出现，而是以异常形式抛出，文本里含 tunnel failed 和数字。要单独捕获这类异常并从中提取错误码，否则你的重试逻辑不会生效。

建议：按渠道统计每天各错误码的比例，输出成简单表格。5xx 比例持续高于其他的渠道应该优先检查，即使它形式上还能用。

预期结果

软件在 502 和 504 时自动带递增暂停和换 IP 重试，遇到 407 立即通知，限制并发流数，并记录区分代理码和网站码的日志。

可能遇到的问题

  • 软件连 407 也重试，导致代理临时封禁地址。完全关闭 4xx 的重试，或把总重试次数降到一次。
  • 开启出错时轮换后 IP 变得太频繁。设置换 IP 的最小间隔，比如 60 秒，避免一串 502 触发五次连续轮换。
  • 日志膨胀到 GB 级。只对带错误码的响应写请求头，200 的只存一行。

检查：50 次请求的测试序列无需手动干预就完成，日志里能看到 5xx 的 5、10、20 秒递增暂停重试，而填入错误密码时软件停止并输出 407 通知。

结果验证：检查清单和测试

逐项对照清单，每一项都打勾。只要有一项没做到，回到对应步骤。

检查清单

  • 带 -v 参数的 curl 命令能执行，你会从输出里找到 CONNECT 的响应行和代理的服务头。
  • 每个渠道在表格里都记录了主机、端口、协议类型、认证方式和编码后的密码。
  • 按 IP 认证时，你机器当前的地址和后台登记的一致。
  • 通过每个渠道的 HTTPS 请求都能让 CONNECT 返回 200。
  • 已测量通过每个渠道的典型首字节时间，软件里的等待上限高于它并留有余量。
  • 软件里只对 502 和 504 配置了重试，暂停为 5、10、20 秒，重试前换 IP。
  • 遇到 407 时软件停止并通知。
  • 每个渠道的流数受限，测试序列里 5xx 比例低于百分之一。
  • 故障日志在维护，且至少有一条完整分析的记录。

测试方法

  1. 故意填错密码并发一次请求。预期：curl 里是 407，软件里是通知，没有一串重试。
  2. 改回正确密码，向稳定网站发 30 次请求，间隔一秒。预期：全部 200，或最多一个 5xx 且重试成功。
  3. 序列进行中，在后台点击换 IP 链接。预期：日志里有一两个 502，随后自动重试并继续序列。
  4. 把一个标注为 HTTP 的渠道设置成 SOCKS5 类型并发请求。预期：tunnel failed 或协议错误，你一秒就能认出来。改回正确类型。

成功指标

工作序列里代理层错误的比例不超过百分之一到二，每个错误都按错误码分类，除 407 外没有一个需要手动干预。对 407 的反应时间是分钟级，而不是小时级。

常见问题与解决

问题：每次重启路由器后都出现 407

原因：用的是按 IP 认证，而运营商给的是动态地址。

解决：改用用户名密码认证，或两种方式都启用。如果必须用 IP，向运营商申请静态地址。

问题：密码是对的，浏览器里 407 但 curl 能过

原因：浏览器或指纹浏览器配置文件缓存了旧数据。

解决：在具体配置文件设置里重新保存代理并重启配置文件，必要时清除代理主机已保存的密码。

问题：每 N 分钟准时报 502

原因：和自动轮换 IP 的间隔吻合。

解决：把软件的暂停与轮换计划对齐，或改用按链接在任务间隙择机换 IP。

问题：流数多时 502，流数少时一切正常

原因：移动渠道过载。

解决：把并发降到每渠道 3-5 个流，并把负载分散到多个渠道。

问题：504 只出现在一个网站上，其他都很快

原因：网站生成页面慢，或对移动运营商地址有限制。

解决：使用网站更轻的地址，重试前换 IP，问题持续就把这个网站的工作转移到其他运营商的渠道。

问题：504 变成了没有错误码的断开

原因：软件里的等待上限小于代理的内部上限。

解决：把软件上限调到你能收到错误码的值，通常 30-60 秒。

问题：tunnel failed, response 400

原因：把 SOCKS5 端口配成了 HTTP 代理，或反过来。

解决：对照后台核对类型和端口，SOCKS5 用 socks5h 方案，HTTP 用 http。

问题：tunnel failed, response 403 到非标准端口

原因：代理不允许到该端口的隧道。

解决：向服务商确认允许的端口列表，尽可能把目标服务改到 443 端口。

问题：502 或 504 响应里带网站的 Server 头

原因：这是网站本身的响应，不是代理层：网站自己的内部服务有问题。

解决：等一会儿再重试；换代理不会有帮助。

进阶用户的额外技巧

如果基础排查已掌握，下面的技巧会让代理层错误的处理几乎自动化。

手动传递认证头

有时需要检查代理对具体头的反应。用本地工具把用户名:密码对编码成 Base64，自己传头：curl -v -x proxy.example.net:8080 -H "Proxy-Authorization: Basic dXNlcjE6cGFzczE=" http://example.com/。这种方式对普通 HTTP 请求有效，能帮你判断代理到底接不接受数据，不管你的软件怎么构造。对 CONNECT 请用 --proxy-header 而不是 -H。

由代理端解析域名

socks5h 方案和 HTTP 隧道都会把域名交给代理服务器，而不是本地解析。这有两个好处：网站看到请求完全来自移动网络，你也摆脱了本地 DNS 给出一个地址而运营商网络给出另一个地址的差异。如果你只在本地解析时看到 502，切到 socks5h 常常不用找服务商就能解决问题。

通过服务商 API 自动化

mobileproxy.space 有用于换 IP 和获取渠道状态的编程接口。把换 IP 调用嵌入 504 处理器，把渠道状态检查嵌入持续 502 的处理器。这样脚本会自己决定是用同一渠道重试还是切到备用。简单算法：一分钟内连续三次 502——查询状态，渠道正常就换 IP，不正常就标记该渠道五分钟不可用并切到下一个。

分离代理和网站的指标

在监控系统里设两个独立指标：带代理服务头回来的错误码，和不带这些头回来的错误码。第一个指标反映你代理基础设施的健康状况，第二个反映目标网站的行为。只要它们混在一起，你就会在错误的地方找代理服务器错误，反之亦然。

带权重的渠道池

给每个渠道分配一个权重，每次 5xx 时降低，随时间慢慢恢复。按权重比例分配请求。这种方式会自动把负载从有问题的运营商或地区移走，等渠道恢复时再把它带回来，无需任何手动切换。

从浏览器导出 HAR

对复杂情况，在指纹浏览器里打开 Network 标签，复现错误并选择「Save all as HAR」。文件包含所有请求和响应头，包括程序普通日志里看不到的阶段。发给支持之前，从文件里删除 Proxy-Authorization 值和 Cookie。

优化等待上限

按渠道和目标收集一周的首字节时间统计。把软件里的等待上限设在 95 分位加 10 秒。这样的上限很少误断活请求，同时能在真正卡住时快速释放流。

FAQ：诊断常见问题

怎么判断 502 是代理返回的还是网站返回的？

看响应头。如果有 Proxy-Agent、Via 等代理服务头，没有网站的 Set-Cookie 和 Server，就是代理返回的。补充一点：如果错误码是随 CONNECT 响应立刻出现的，那一定是代理。

407 时该重试请求吗？

不该。凭据不会因为重试就变对，而一排失败尝试可能导致你的地址在代理侧被临时封禁。改好数据后只重试一次。

为什么 curl 能行而我的软件不行？

最常见的是软件构造代理字符串的方式不同，没有对密码里的特殊字符编码，用了不同的协议类型，或者在 CONNECT 时没传认证。把软件设置里的确切字符串和可用的 curl 命令逐字符对比。

密码里有特殊字符该怎么写？

在地址字符串里要编码：@ 写成 %40，: 写成 %3A，# 写成 %23，% 写成 %25，空格写成 %20。在单独的用户名和密码字段里按原样输入，不编码。

504 和其他文章里说的超时有什么区别？

504 是代理自己等到网站等待上限后返回的错误码。没有错误码的超时意味着你的客户端没收到任何东西就断开了。两者处理方法不同，所以放在不同材料里。

一个移动渠道可以跑多少个流？

没有通用数字。从 3-5 开始，逐步提高，直到 502 比例低于百分之一。重页面数字会小些，轻量 API 请求会大些。

每个错误都要换 IP 吗？

504 和持续 502——要，这是第一步。407——不要，换 IP 不影响认证。设置换 IP 的最小间隔，避免一串错误引发轮换雪崩。

该给支持发什么才能更快解决问题？

把密码替换成星号后的完整 curl -v 输出、精确到秒并带时区的准确时间、渠道主机和端口、目标域名、认证方式，以及不走代理直连的结果。有了这套信息，支持通常第一条回复就能解决。

连接代理本身可以用 HTTPS 吗？

只有服务商明确支持时才可以用。大多数情况下，移动代理的连接走普通 HTTP 或 SOCKS5，到网站的流量加密由隧道负责。给代理连接额外开加密会导致 tunnel failed 或握手错误。

结语

你已经从日志里一行看不懂的红色文字，走完了一套完整的排查系统。现在你能判断到底是谁返回了响应，把 407 读成检查凭据和认证方式的信号，把 502 看成代理之后或轮换时刻的故障迹象，把 504 看成代理对慢网站的诚实报告，把 tunnel failed 看成这些错误码的外壳并附带数字提示。你的软件不再做无意义的重试，也不会在临时问题前放弃。

接下来做什么

  1. 至少坚持记录一个月故障日志。两周内你就会发现重复出现的模式，并消除它们的根因。
  2. 每周复盘一次各渠道的错误码比例，重新分配负载。
  3. 通过服务商 API 自动化换 IP 和状态检查，让常规 5xx 无需你介入。
  4. 学习博客里关于网络超时和目标网站行为的相关材料，补全请求路径剩下的两段。

发展方向

下一个层次是建立自己的带权重和监控的渠道池，在那里代理服务器错误不再是惊慌的理由，而是图表上的一个点，系统会自行处理。你已经拥有所有工具：对错误码的理解、curl、服务商后台，以及记录的习惯。祝你工作顺利，200 常伴。