GOST v3 实战：为多个采集程序提供统一代理入口

当 Python、Node 和浏览器采集程序需要使用同一出口时，在每个客户端里重复维护上游配置会增加切换和排错成本。GOST 可以提供统一入口，再把请求转发到指定上游。

本文建立两个客户端入口：HTTP 与 SOCKS5，它们连接同一 HTTP 上游。先通过命令确认路径，再把配置保存为文件，最后解释开发机与容器里的地址差异。范围是 GOST v3 的正向转发，不涉及透明代理或全机流量接管。

准备镜像与真实上游

需要已安装的 Docker，以及一个你可使用的上游代理。检查镜像版本：

docker pull gogost/gost
docker run --rm gogost/gost -V

默认镜像标签会随发布变化。确认输出是所需的 v3 系列，并在实际部署中保存镜像标识；升级时不要把 v2 配置直接混入 v3。也可从 GOST 官方 Releases 下载对应操作系统与 CPU 架构的二进制。

以下上游地址是占位示例，需要换成真实配置，密码中的特殊字符按 URL 组件编码：

export UPSTREAM_URL='http://user:pass@proxy.16yun.cn:8888'

-L 指定本地监听，-F 指定转发节点。两个 -L 是两个入口；多个 -F 通常表达转发链，不应直接当作同级随机代理池。参数语义见 GOST v3 CLI 文档。

启动两个入口，使用同一个转发链

执行下面的完整命令：

docker run --rm --name crawler-gateway   -p 127.0.0.1:18080:8080   -p 127.0.0.1:11080:1080   gogost/gost   -L 'http://:8080'   -L 'socks5://:1080'   -F "$UPSTREAM_URL"

容器内监听端口分别是 8080 与 1080，宿主机映射为 18080 与 11080。宿主机发布限定回环地址，适合当前开发机使用；它不是供整个局域网访问的默认配置。

在另一终端检查两种客户端协议：

curl --max-time 20 --noproxy ''   --proxy http://localhost:18080 https://httpbin.org/ip
curl --max-time 20 --noproxy ''   --proxy socks5h://localhost:11080 https://httpbin.org/ip

这里 socks5h 让 curl 将目标主机解析交给代理侧处理。HTTP 入口也能通过 CONNECT 访问 HTTPS 目标；入口协议和目标 URL 协议不是一回事。

把命令转换成可维护的配置

停止刚才的实例后，导出与命令对应的 YAML：

docker run --rm gogost/gost   -L 'http://:8080' -L 'socks5://:1080'   -F "$UPSTREAM_URL" -O yaml > gost.yaml
chmod 600 gost.yaml

查看文件中的 services、chains、hops 和节点，确认两个监听与预期上游一致。导出文件可能包含上游认证信息，应按本地秘密配置管理，不提交公开仓库。

再通过配置文件启动：

docker run --rm --name crawler-gateway   -p 127.0.0.1:18080:8080   -p 127.0.0.1:11080:1080   -v "$PWD/gost.yaml:/etc/gost.yaml:ro"   gogost/gost -C /etc/gost.yaml

重新执行两条 curl，对比输出是否仍包含有效 origin。配置导出避免手工猜测 YAML 层级，但仍需核对业务含义。文件结构见官方配置说明。

不要一边把旧的 -L/-F 参数保留在服务启动命令里，一边期待文件修改完全接管行为。实际生效配置可能受命令行及环境设置影响；改变配置后必须检查服务启动参数与实际请求。

怎样让采集程序使用这个网关

开发机上的 HTTP 客户端使用 http://localhost:18080，支持 SOCKS 的客户端使用对应的 11080 端口。上游认证由网关处理，但应用仍需按自己库的接口配置入口。

另一个容器不能用自己的 localhost 指向宿主机网关。推荐把调用方与网关放入同一自定义 Docker 网络，用网关容器名和容器内端口访问。例如网络名为 crawler-net 时，先创建网络，再在启动网关时加 --network crawler-net：

docker network create crawler-net

调用方同样加入该网络后，HTTP 代理主机填写 crawler-gateway，端口填写 8080。这时 18080 是给宿主机使用的映射端口，不是容器间访问端口。网关监听在共享网络中可达，应只让所需调用方加入，并根据实际共享范围配置入口认证。

检查结果与上游切换

回显响应应有 origin 字段，其值属于实际网络出口。两个入口的结果不必永远是相同 IP：如果上游本身轮换，两个独立请求可能分配不同出口。网关并不自动提供固定会话 IP。

切换上游时，先保存旧配置，修改转发节点后重启当前实例，并用相同目标进行连通性检查，再检查真实采集页面。不要只看容器处于 running；running 只能说明进程尚未退出。

如果任务登录状态依赖出口，不要在任务中途随意改链路。应先结束或明确迁移任务会话，再启用新配置，避免账号、Cookie 与出口条件发生无法解释的组合变化。

常见问题与定位

宿主机连不上端口。 检查容器是否正常启动、端口映射是否一致、是否已有同名或同端口实例。先解决入口连接，再检查上游密码。

HTTP 可用、SOCKS 不可用。 核对客户端是否真支持 SOCKS，是否把 18080 与 11080 搞反，以及本地和代理侧 DNS 行为是否符合要求。

返回上游认证错误。 检查 -F 节点凭据和编码，而不是把账号加到错误的 -L 入口。入口认证与上游认证是两层配置。

改了文件却没有变化。 检查挂载路径是否正确、容器是否重启，以及启动参数里是否仍有覆盖配置。先确认读的是新文件，再排查网络。

网关成功但目标数据错误。 回到页面身份、登录、地区和字段提取。统一转发解决的是链路管理，不会自动修复业务结果。

停止与回退。 用实际终端 Ctrl+C，或执行 docker stop crawler-gateway。需要回退时恢复保存的旧配置并重新做两层检查，不同时留下两个争抢端口的实例。

统一入口的价值，是减少客户端重复配置，同时保留清楚的链路。转发规则、会话约束与业务检查仍需分别管理。