wproxy使用教程

第一次接触 wproxy 是使用在去年帮朋友排查一个爬虫项目。他抱怨说目标网站封 IP 封得厉害，教程换了几个代理池都不稳定。使用我扔给他 wproxy 的教程安装包，他折腾半小时后回了一句：“这东西怎么连日志都看不懂？使用”——问题不在工具，在没人把配置逻辑讲清楚。教程下面这些内容，使用是教程我自己踩过坑之后总结的用法，不保证全面，使用但能让你少走弯路。教程

装完之后先别急着跑

wproxy 的使用安装没什么好说的，Windows 下解压双击，教程Linux 下给个执行权限就完事。使用真正容易卡住的教程是第一次启动。默认配置文件里监听地址写的使用是 127.0.0.1:8888，如果你打算让局域网里其他机器也用，得改成 0.0.0.0:8888。我见过有人在这卡了一下午，以为软件坏了，其实只是没改绑定地址。

配置文件是 JSON 格式，字段不多，但有个细节：upstream 和 rules 的顺序会影响匹配结果。wproxy 从上往下读规则，第一条命中就停。你要是把 allow all 写在最前面，后面的限制规则全成摆设。我自己的习惯是把最具体的规则放顶部，宽泛的放底部，跟写防火墙策略一个道理。

代理链怎么配才不绕晕

wproxy 支持多级代理串联，配置写法是在 upstream 里写数组。比如你要先走公司内网代理再走外部 SOCKS5，就按顺序填两个对象。这里有个坑：如果第一级代理需要认证，auth 字段必须用 user:pass 的格式，别拆成两个字段。我第一次配的时候想当然地写了 username 和 password，结果 wproxy 静默忽略，直接连下一级去了，日志里连个警告都没有。

调试代理链有个笨办法但很管用：把每一级单独拿出来用 curl 测。比如 curl -x socks5://127.0.0.1:1080 http://httpbin.org/ip，确认单级通了再串起来。wproxy 的日志级别调到 debug 后会打印每一跳的握手信息，但输出量很大，建议只在排查时开。

规则匹配的坑比想象中多

wproxy 的规则支持域名通配和正则。写 *.example.com 能匹配 api.example.com，但匹配不到 example.com 本身——这个行为跟很多人的直觉相反。要同时覆盖主域和子域，得写两条或者用正则 (.*\.)?example\.com。我因为这个问题丢过一次生产环境的流量，后来养成了习惯：每条规则写完都用 wproxy --test-rule 跑一遍。

另一个容易忽略的是规则优先级和 direct 的关系。如果你想让内网地址直连、其他走代理，规则顺序应该是：先写内网网段的 direct，再写 proxy all。反过来写的话，内网请求也会被扔进代理链，轻则慢，重则因为代理服务器访问不了内网而超时。

日志和监控别等出事才看

wproxy 默认把访问日志写到标准输出，生产环境建议重定向到文件并配合 logrotate。日志格式是类 Apache 的 common log，但多了一个 upstream_time 字段，单位是毫秒。这个值突然飙高通常意味着代理链里某一跳出了问题。我自己的做法是用 awk 每五分钟统计一次 upstream_time 的 P95，超过 2000ms 就发告警。脚本很简单，但比事后翻日志强得多。

还有个小功能值得开：health_check。wproxy 会定期探测 upstream 的可用性，失败超过阈值自动摘除。配置里 interval 别设太短，10 到 30 秒比较合适，太短反而会因为网络抖动误判。这个功能在代理池场景下特别有用，省得自己写健康检查脚本。

最后说一句：wproxy 的文档不算友好，但源码里 config.go 和 rule.go 两个文件把配置逻辑写得很清楚。遇到文档没讲明白的地方，直接翻源码比搜博客快。我现在的习惯是每换一个版本，先 diff 一下这两个文件，看看有没有新增字段或行为变更。这比读 changelog 靠谱。