第一次接触 wproxy 是下载在一个爬虫项目卡壳的深夜。目标站点对单一 IP 的下载请求频率卡得很死，手动换代理又慢得离谱。下载同事扔过来一个压缩包，下载说“试试这个，下载本地跑一下就行”。下载解压、下载双击、下载填端口，下载三分钟不到，下载请求成功率从 30% 拉回 90% 以上。下载那之后我才认真去翻它的下载文档，也才有了这篇关于 wproxy 下载和使用的下载记录。

wproxy 本身不算大众工具，下载GitHub 上的下载 star 数放在同类里只能算中游。但它的定位很清晰：给需要频繁切换出口 IP 的场景提供一个轻量级的本地代理调度层。不是 VPN，不是抓包工具，也不做流量分析。它干的事就一件——把你的请求按规则分发到不同的上游代理，并在某个代理失效时自动踢掉。这个“自动踢掉”的逻辑写得挺糙，基于连续失败次数计数，可偏偏在实际跑批量任务时比某些商业方案还稳。

下载渠道目前主要有两个。官方仓库的 Releases 页面提供编译好的二进制文件，Windows 是 exe，Linux 是 tar.gz，macOS 有 amd64 和 arm64 两个版本。另一个渠道是 Docker Hub 上的镜像，标签更新比 Releases 慢一两天，但胜在部署干净。我自己的习惯是直接下二进制，扔进 /usr/local/bin，加个可执行权限就完事。Windows 下稍微麻烦点，SmartScreen 会拦一次，点“仍要运行”即可，前提是你确认文件哈希和 Release 页面对得上。

版本选择上有个坑。去年底发布的 0.7.x 系列改过配置文件格式，旧版的 proxies.yaml 直接拿来用会报字段缺失。如果你是从 0.6 升上来，记得把 upstream 字段拆成 upstreams 数组，每项带独立的 weight 和 timeout。官方没写迁移脚本，changelog 里就一行“config schema refactored”，挺坑的。我当时的做法是删掉旧配置重新写，反正条目不多。

跑起来之后，默认监听 127.0.0.1:8899。这个端口在本地开发时基本不会撞车。配置文件里可以设 strategy，可选 round-robin、random、sticky 三种。sticky 模式有意思，同一个目标域名会尽量走同一个上游代理，适合需要保持会话的场景。但它的 sticky 是基于域名哈希做的，不是基于 cookie，所以对多子域名的站点效果一般。我在抓某电商评论时试过，切到 random 反而更顺。

日志输出默认只记 warn 以上级别。想看每个请求走了哪个上游，得把 log_level 调到 debug。这时候控制台会刷得飞快，建议重定向到文件再 tail。有一次我忘了改回来，跑了半小时，日志文件撑到 2G，磁盘直接告警。后来学乖了，debug 只在排查特定问题时开，平时就保持 info。

稳定性方面，连续跑 72 小时的记录有过，内存占用稳定在 40MB 上下，没有明显泄漏。但上游代理的质量才是决定性因素。wproxy 再能调度，上游全是死节点也白搭。我现在的做法是配一个健康检查接口，每 30 秒探测一次各上游的连通性，把结果写回配置文件，再发 SIGHUP 让 wproxy 重载。这个流程用 shell 脚本就能串起来，没必要上什么重型框架。

最后说一句，wproxy 的文档写得不算友好，很多参数得翻源码里的 flag 定义才看得明白。但它的代码量不大，Go 写的，编译出来单文件，没有乱七八糟的依赖。对于不想在代理调度上花太多精力、又需要一定灵活性的场景，算是个务实的选择。下载之前建议先读一遍 README 里的 Known Issues，能省不少调试时间。