mubeng 使用教程：检测代理清单并接入轮换采集

拿到一份代理清单后，不能直接假设每个节点都可用；能访问检查站点，也不代表能完成你的目标采集。mubeng 提供清单检查与轮换入口，适合先整理可达节点，再接入实际任务观察。

本文使用你已经持有的代理节点，完成“清单 → 检查 → 可用池 → 本地 HTTP 入口 → 请求对照”。不包含公共代理收集，也不把一次检查通过写成长期可用保证。

安装与输入格式

从 mubeng 官方 Releases 下载匹配系统的二进制，放入 PATH。已安装 Go 的环境也可以安装指定版本：

go install github.com/mubeng/mubeng@v0.23.0
mubeng -V
mubeng -h

确保 Go 的 bin 目录在 PATH 中。记录实际版本，后续参数以该版本帮助为准。官方仓库的使用说明区分 check 与 server 两种方式。

创建 proxies.txt，一行一个完整代理 URL。下列为格式占位符，必须替换为真实自有节点：

http://user:pass@proxy-a.example.16yun.cn:8888
socks5://user:pass@proxy-b.example.16yun.cn:1080
http://localhost:1

第三行可以作为本机无服务端口的失败材料，但不能预先断言任何机器的端口 1 都一定没有监听。真实凭据不提交 Git；特殊字符应按 URL 组件编码。

先小并发检查，再查看可用清单

执行：

mubeng -f proxies.txt --check   --goroutine 5 --timeout 10s --output live.txt

并发五与十秒超时是小清单的起步设置。超时太小会把慢节点归为不可用，太大则延长失效节点等待；应结合你实际网络调整。

检查结束后查看 live.txt，确认输出确实是本版本可再次读取的代理清单。如果使用了自定义输出模板，不应把带有统计列的报告原样当作下一阶段代理输入。空文件表示本轮没有合格节点，不能继续启动一个预期可用的池。

本例使用默认检查目标与判定。它证明的是工具所采用检查路径的结果，不是任意目标网站都能访问。需要针对某业务源评估时，还要通过实际请求做第二层检查。

启动本地轮换入口

把合格清单作为输入，启动本地 HTTP 服务：

mubeng --address 127.0.0.1:8089 --file live.txt   --rotate 2 --method sequent --sync

这个入口对客户端提供 HTTP 代理；输入池支持 SOCKS 节点，不意味着对外入口也变成 SOCKS。不要把客户端代理 URL 写成 socks5://localhost:8089。

--rotate 2 表示按工具请求计数切换节点，不是每两秒切换。官方说明中失败请求也参与计数，默认异步处理也不保证你在外部观察到严格的第 N 次边界。本例添加 sync 便于理解顺序，代价是请求串行化，不作为高吞吐配置。

用独立请求观察，而非凭页面数量猜轮换

保持服务运行，在另一个终端逐次执行：

for number in 1 2 3 4; do
  printf 'request %s: ' "$number"
  curl --silent --show-error --max-time 20 --noproxy ''     --proxy http://localhost:8089 https://httpbin.org/ip
  printf '\n'
done

每个 curl 都是一个独立客户端进程，避免把浏览器的一页、多资源请求和连接复用混在一起。输出应按实际 origin 记录；不能预先承诺前两次与后两次一定不同，因为不同代理节点也可能共享出口，上游本身也可能轮换。

如果需要证明走过不同节点，还要结合工具日志与自有节点信息，而不是只比较 IP 字符串。不要为了调试在共享日志中打开完整请求转储，里面可能包含代理凭据或业务请求内容。

接入采集程序时要重新考虑会话

采集程序指向 http://localhost:8089 即可使用这个入口，但要通过回显或连接记录确认库没有绕过代理。客户端处于其他容器时，localhost 的含义也会变化。

无登录的独立页面可以逐请求轮换。需要 Cookie 与固定出口关联的任务，应使用任务级固定节点或明确的会话策略，不能无条件把所有请求送入轮换池。增加轮换频率不自动提高任务成功率。

初次接入不启用无限重试。本例没有设置 rotate-on-error，避免在排错时不断切节点掩盖根因。之后若添加错误轮换，设置有限错误次数，并区分节点连接失败、上游认证、目标限流和页面解析错误。

清单更新与结束

重新检查时输出到新文件，先核对节点数量和格式，再替换运行池使用的清单。需要自动重载时，检查该版本 watch 的行为，并保留旧清单便于回退。

当前前台服务用 Ctrl+C 停止。本例没有使用 daemon 参数，因为将它安装成系统服务会改变管理方式；确需后台运行时由实际服务管理器定义启动、重启与停止，而不是让每个采集脚本随意创建一个新轮换进程。

常见问题与修复

检查结果全为空。 先直接检查一个已知节点的主机、端口、认证与协议，再看本地网络是否能访问默认检查目标。不要先增加线程数。

live 清单非空却无法转发。 确认文件格式没有混入颜色、统计或 JSON 包装，再核对服务启动日志和当前节点状态。检查与使用之间节点可能已经失效。

IP 看起来没有变化。 检查请求计数、sync 设置、节点是否共享出口，以及是否存在长连接。IP 相同并不能独自证明轮换失败。

登录反复失效。 检查任务是否要求固定出口。给该任务固定节点，重新建立会话，再对照是否恢复；不要无限放大重试。

一失败就删节点，清单越用越少。 目标站错误不一定表示节点失效。不要把业务解析错误当成移除代理的依据，先明确错误分类与恢复规则。

HTTP 可用、某个 HTTPS 目标不可用。 检查节点 CONNECT 能力、目标访问条件与证书错误。不要跳过证书验证来制造成功状态。

清单检查、轮换入口和目标任务检查是三个阶段。把它们分别记录，才能知道应该换节点、调整会话，还是修复采集逻辑。