go-proxyproto PROXY 免费下载

12次阅读

获取下载链

微信关注「软件教程管家」公众号，回复 go-proxyproto

go-proxyproto 是一款面向 Go 的 PROXY协议实现，解决的是代理或负载均衡链路之后、后端服务看不到真实客户端地址的问题：当前端代理转发请求时，它把原始连接信息装进协议头带给后端，让 Go 服务在代理后面依然能拿到真实的客户端地址与连接信息。

项目信息

项目	内容
软件名称	go-proxyproto
类型	Go 网络库（PROXY Protocol 实现）
适用平台	多平台（Go 可运行环境）
协议版本	PROXY Protocol 版本 1 与版本 2
传输覆盖	TCP、Unix 流、UDP、TLS、HTTP
运行要求	据源稿介绍，需 Go 1.26.9 或更高版本，以仓库 README 为准
许可证	Apache-2.0（以仓库声明为准）
获取方式	GitHub 仓库（见文末 GitHub 获取说明）

PROXY协议版本选择：v1 还是 v2

PROXY协议有两个版本，选错会导致对端解析失败，接入前必须先确认链路两端用的是同一版本。版本 1 是文本头，人可读、排错直观，适合已有文本协议处理链路或需要快速抓包确认的场景；版本 2 是二进制头，结构更紧凑，适合对解析效率与扩展字段有要求的场景。据源稿介绍，本库同时覆盖两个版本，因此版本选择不由库决定，而由你的代理与后端约定决定：两端约定一致即可，混用是接入失败最常见的源头。

传输形态同样要先定：TCP 与 Unix 流走流式接口，UDP 则每个数据报都要携带协议头，不能把流式处理方式直接套到 UDP 上。TLS 场景还要先处理 PROXY 头、再建立或移交 TLS 连接，顺序颠倒同样无法正常工作。

安装与接入步骤

确认运行环境满足 Go 版本要求：据源稿介绍需 Go 1.26.9 或更高版本，升级前先核对现有工具链版本。
把本库引入 Go 项目：模块路径与仓库地址对应，引入后按仓库 README 的示例从客户端、服务端、TLS 或 UDP 场景选一条先跑通。
服务端接入：用库提供的 Listener 包装监听器，让连接在进入业务逻辑之前先完成协议头读取与解析。
客户端接入：发送端用 Header.WriteTo 写入协议头，UDP 场景用 Header.FormatUDPDatagram 生成带协议头的数据报。
接收与解析：流式连接用 NewConn 与 Read 处理前置头，UDP 场景用 ParseUDPDatagram 解析每个数据报携带的协议头。
先用仓库自带的 HTTP、HTTP/2、TLS、UDP 与 net.PacketConn 示例验证一遍，再把接入方式搬进自己的服务。

必改设置：接进生产前必须定好的 5 项

可信来源策略：只允许明确配置的可信代理对端发送 PROXY 头，绝不把要求 PROXY 头的监听端口直接暴露给不受信任的客户端，否则来源地址可被伪造。
协议版本约定：与代理端书面约定版本 1 或版本 2，并在两端同时固化，杜绝一端升级、另一端未同步的混用。
传输形态分流：TCP 与 Unix 流走流式接口，UDP 走数据报接口，两类代码路径分开写、分开测，不共用同一套处理假设。
TLS 处理顺序：TLS 场景先完成 PROXY 头处理，再建立或移交 TLS 连接，并按 README 确认该顺序在自己的接入方式下成立。
HTTP/2 构造方式：新集成优先查看基于 HTTP2Config 的构造方式，旧的 golang.org/x/net/http2.Server 构造函数据源稿介绍已标记为弃用，不建议新代码继续采用。

注意事项

PROXY 头会替换应用看到的客户端地址：这正是它的用途，也是它的风险点——一旦非可信对端能发头，日志、限流与风控看到的来源就全不可信。
默认配置要求 PROXY 头，但仍可能接受任意对端提供的头：不要以为“开了 PROXY 解析就等于安全”，可信来源控制必须另外配。
UDP 没有流的概念：每个数据报都要自带协议头，丢包、重排与分片场景下的处理要按数据报语义单独验证。
Go 版本门槛较高：据源稿介绍需 Go 1.26.9 或更高版本，较旧环境无法直接使用，升级工具链前先评估对其他依赖的影响。
公开信息有限：更细致的兼容性、错误处理与维护状态需结合仓库 README 或源码确认，不要只凭摘要做生产决策。

适用人群与对比取舍

适合人群：需要在 NAT、负载均衡器或代理链路之后保留原始客户端信息的 Go 开发者，尤其适合自行控制 PROXY 协议收发两端的网络服务维护者。明确取舍：如果代理层已由基础设施统一处理协议头、应用层并不需要再解析一次，就不必引入这个库；如果业务只涉及普通 TCP 且已有成熟的头透传方案，也应先确认是否真的需要应用层再做一次解析。反过来，当后端必须在应用层拿到真实客户端地址、且链路两端都可控时，这个轻量接入层就是合适的选择。