frp与nps传到到本地Nginx中的Brotli 压缩链路验证记录
› VFX大学 › Linux/macOS 与自动化运维 › frp与nps传到到本地Nginx中的Brotli 压缩链路验证记录

-
作者帖子
-
-
2025年7月20日 - 下午7:19 #797
追光管理员目标: 确认 Brotli 压缩发生在哪一端(后端 Nginx 还是反向代理),并验证 FRP 穿透架构下的压缩状态。
一、测试背景
-
架构:
浏览器 → 公网服务器 (Nginx 反代) → FRPS → FRPC → 本地 M1 Pro (Nginx 后端)
-
公网服务器:未安装 Brotli 模块,仅有 gzip 模块,且未启用压缩。
-
本地 Nginx:启用了 Brotli 压缩(brotli on;)。
-
反向代理配置透传 Accept-Encoding:
proxy_set_header Accept-Encoding $http_accept_encoding;
-
目标 URL:
https://x.newvfx.com/129091.html
二、测试方法
1. 注入标识 Header
为了区分压缩来源,在两端 Nginx 配置中添加自定义 Header:
后端(本地 Nginx)
add_header X-Backend "Compressed by NewVFX Server" always;
反代(公网服务器)
add_header X-Proxy "Compressed by Cloud server" always;
2. 使用 curl 模拟请求
发送请求时,显式声明浏览器支持 Brotli 和 Gzip:
curl -I -H "Accept-Encoding: br,gzip" https://x.newvfx.com/129091.html
解释:
-
-I:只请求响应头。
-
-H “Accept-Encoding: br,gzip”:模拟浏览器压缩偏好。
三、测试结果
3.1 浏览器请求结果
HTTP/2 200 date: Sun, 20 Jul 2025 11:06:38 GMT content-type: text/html; charset=UTF-8 content-encoding: br link: <https://x.newvfx.com/wp-json/>; rel="https://api.w.org/" link: <https://x.newvfx.com/wp-json/wp/v2/posts/129091>; rel="alternate"; title="JSON"; type="application/json" link: <https://x.newvfx.com/?p=129091>; rel=shortlink vary: Accept-Encoding x-backend: Compressed by NewVFX Server x-proxy: Compressed by Cloud server server: NewVFX H3 Engine strict-transport-security: max-age=31536000
核心字段:
-
content-encoding: br → 内容最终是 Brotli 压缩。
-
x-backend: Compressed by NewVFX Server → 后端执行了压缩。
-
x-proxy: Compressed by Cloud server → 仅表明经过代理,并非真实压缩行为。
-
Server: NewVFX H3 Engine → 标识为自定义服务端。
3.2 直接请求反代上游(127.0.0.1:55080)
curl -I -H "Accept-Encoding: br,gzip" http://127.0.0.1:55080/129091.html
结果:
HTTP/1.1 404 Not Found
(因测试环境未配置直链访问,不影响验证结论)
四、结论
-
压缩发生在本地后端 Nginx
-
公网反代无 Brotli 模块,无法压缩。
-
Header x-backend 表明本地执行压缩。
-
-
反代只做透传
-
proxy_set_header Accept-Encoding $http_accept_encoding; → 浏览器的压缩偏好直接传递到后端。
-
公网反代未开启 gzip/Brotli,且未二次压缩。
-
-
链路状态
浏览器 (br,gzip) → 公网反代 (仅透传) → 本地 Nginx (Brotli 压缩) → FRP 隧道(传输已压缩内容)
-
为何本地环境 100% Brotli,而 VPS 有时 gzip?
-
VPS 环境 Brotli 模块缺失,只能返回 gzip。
-
本地 Nginx Brotli 模块开启 → 永远 Brotli。
-
五、附录:完整验证命令
# 验证响应头 curl -I -H "Accept-Encoding: br,gzip" https://x.newvfx.com/129091.html # 验证代理是否修改压缩行为 curl -I -H "Accept-Encoding: br,gzip" http://127.0.0.1:55080/129091.html
✅ 测试结论:架构已经最优,压缩只在性能最强的 M1 Pro 后端执行,FRP 传输的是压缩后的数据,节省带宽,最大化速度。
-
-
2025年7月20日 - 下午7:24 #800
追光管理员补充说明
在当前架构下,压缩行为完全由后端(本地)服务器控制,反代服务器仅做透明转发,不参与实际压缩过程。具体表现和测试案例如下:
-
关闭后端压缩时,通过 curl 请求,响应头中 Content-Encoding 变为 gzip,说明反代服务器使用自身的 gzip 模块进行压缩。
-
开启后端压缩时,响应头中的 Content-Encoding 变为 br,且带有自定义响应头 x-proxy: Compressed by Proxy,表明内容由后端以 Brotli 压缩后传递给反代,反代不再二次压缩。
测试示例
# 关闭后端 br 压缩,查看响应头 curl -I -H "Accept-Encoding: br,gzip" https://x.newvfx.com/129091.html HTTP/1.1 200 OK Content-Encoding: gzip x-proxy: Compressed by Proxy ... # 开启后端 br 压缩,查看响应头 curl -I -H "Accept-Encoding: br,gzip" https://x.newvfx.com/129091.html HTTP/1.1 200 OK Content-Encoding: br x-proxy: Compressed by Proxy ...
结论
-
压缩逻辑单一明确:后端负责内容压缩,反代服务器不做压缩,仅转发。
-
避免重复压缩和性能浪费:防止反代和后端同时压缩导致 CPU 资源浪费和兼容性问题。
-
更灵活的压缩策略:后端可以根据自身负载和内容类型灵活选择 gzip 或 br 压缩方式。
-
简化维护与调试:通过在响应头添加自定义标识,快速定位压缩源头,方便排查和优化。
这种架构特别适合需要反向代理穿透本地服务,同时对传输效率和兼容性有较高要求的场景。
-
-
2025年7月20日 - 下午7:30 #803
追光管理员总结如下:
1. 后端服务器负责压缩(支持 Brotli 或 gzip),最终生成压缩后的响应内容。
2. 反代 Nginx 仅负责透传压缩后的数据,不对数据再次压缩,避免重复压缩带来的性能浪费。
3. FRP 层无需开启压缩,保持数据透明传输,降低 CPU 负载,提高传输效率。这样架构确保压缩控制集中在后端,链路更简洁,性能和稳定性更优。
-
-
作者帖子
- 在下方一键注册,登录后就可以回复啦。