入站 PROXY Protocol 与上游代理头
网关需要区分两种方向相反的代理信息：前置负载均衡器可通过 PROXY Protocol 告诉 fn-knock 真实连接地址；fn-knock 则可通过 X-Forwarded-* 等 Header 把访问信息传给业务上游。两者的信任边界和配置位置不同。
接收入站 PROXY Protocol
经过 HAProxy、Nginx stream 或其他四层负载均衡器时，可在 系统设置 → 网关 → PROXY Protocol 启用 v1 / v2 接收，并填写允许发送该协议的代理 IP 或 CIDR。这里填写的是与 fn-knock 建立 TCP 连接的代理节点地址，不是访客地址。
启用后至少需要一个可信来源。配置只接受 IP 或 CIDR，会规范化并去重；不能填写域名，也不能使用覆盖全部 IPv4 或 IPv6 的网段。只有列出的 socket 对端可以提交 PROXY 头，其他来源仍可按普通连接访问，但不能借助伪造的 X-Forwarded-For 或 X-Real-IP 覆盖 PROXY 地址。
PROXY Protocol 本身不提供鉴权。不要照搬客户端白名单，也不要信任公网大网段；负载均衡器应使用固定内网地址，并在网络层限制谁能到达网关。托管 FRP 会自动启用其所需的有效 PROXY Protocol 配置，页面会标记该托管状态，无需把 FRP 访客地址加入可信来源。
保存配置时会先验证并应用网关运行配置；应用失败时不会留下只在磁盘或只在运行时生效的半套设置。修改后应从外部链路发起请求，在请求日志同时核对 socket 对端与客户端 IP。
向上游传递 HTTP 代理头
通过 fn-knock 反向代理请求时，上游服务可能需要知道原始协议、访问 Host 或客户端地址。系统设置 → 网关 → 协议头 按反向代理业务 Host 控制网关是否向上游发送 X-Forwarded-* 等代理头。它仅在 Host 路由的子域模式中可编辑，包括公网直达 子域模式 与 内网穿透 → 子域映射；路径模式、直连模式和静态文件或目录响应不提供此项，因为静态响应没有上游。
启用后，上游应用可以基于这些头生成正确的外部链接、判断 HTTPS、记录客户端地址或配置自身的可信代理。关闭后，应用通常只会看到 fn-knock 与它之间的连接信息。
界面只列出反向代理 Host，但运行时按上游 Target 生效。多个 Host 复用同一个 Target 时，关闭其中一个 Host 的协议头会影响其他复用该 Target 的 Host；需要不同策略时，为它们使用不同 Target。
上游需要配合
发送代理头只提供信息，不会让上游自动使用它们。还需在应用或其前置 Web 服务器中：
- 把 fn-knock 的连接地址或所在网段配置为可信代理。
- 指定实际使用的协议头名称。
- 检查外部 URL、HTTPS 判断和访问日志中的客户端 IP。
若上游信任所有来源提供的 X-Forwarded-For，攻击者绕过 fn-knock 直连上游时可以伪造地址。应同时收敛上游监听范围或用防火墙只允许 fn-knock 访问。
使用原则
- 只有在上游应用需要并且能正确处理这些头时启用。
- 上游应用应只信任来自 fn-knock 的代理头；不要让它接受任意客户端伪造的
X-Forwarded-For。 - CDN、FRP 或 Tunnel 在 fn-knock 前面时，前置链路必须删除或重写外部客户端可伪造的真实 IP 头；再从请求日志确认 fn-knock 识别到的客户端 IP。
- 修改后用请求日志和上游访问日志对照 Host、协议、客户端 IP。
这个设置只影响 fn-knock 发给上游 的头，不决定 fn-knock 如何识别入站客户端 IP，也不能充当可信代理名单。入站来源识别依赖前置链路正确处理真实 IP 头；部署后必须在请求日志中核验。