用内网穿透工具的时候，不少人会注意到一个参数——压缩率。有时候打开日志一看，压缩率才20%，甚至更低，心里就开始打鼓：这正常吗？是不是哪里出问题了？
压缩率低不等于一定有问题
先说结论：压缩率偏低本身并不一定代表有故障。关键要看你传的是什么数据。比如你正在传输一堆已经压缩过的文件，像MP4视频、JPEG图片、或者ZIP包，这些内容本身就已经“挤干”了水分，再压缩空间非常有限。这时候即使算法全力工作，压缩率也只有10%~20%，属于正常现象。
反过来，如果你传的是一堆原始日志文本、未压缩的JSON数据或纯HTML文件，压缩率却只有个位数，那才值得怀疑是不是配置没生效，或者网络中间件干扰了数据流。
怎么判断压缩有没有起作用？
可以做个简单测试：找一段重复性高的文本，比如连续几十行的aaaaaa，通过你的内网穿透服务发一次。如果压缩开启，这类数据通常能压到原来的30%以下。如果还是接近1:1传输，那可能是压缩功能被关闭了。
以 frp 为例，客户端配置中需要明确开启：
[common]
server_addr = x.x.x.x
server_port = 7000
[web]
type = tcp
local_port = 80
use_compression = true
use_encryption = true注意 use_compression = true 这一项，不打开它，所有流量都是原样走的。有些用户图省事复制旧配置，忘了加这一行，结果一直“零压缩”跑了几个月都没察觉。
压缩开不开，影响有多大？
如果你的公网带宽小，比如只有5Mbps，又常传大文件或网页资源，不开压缩可能明显拖慢访问速度。开了之后，文本类内容体积缩小一半很常见，加载自然更快。但代价是服务器CPU使用率会上升一点，尤其是并发连接多的时候。
所以有些人为了稳定，宁愿关掉压缩保性能。特别是跑数据库代理、远程桌面这类对延迟敏感的服务，压缩反而可能引入轻微延迟，得不偿失。
实际场景举例
老张做监控系统，用内网穿透把摄像头画面传出来。他发现压缩率始终低于10%。其实这很正常，H.264视频流本身就是高压缩格式，再压也压不出多少。但他后来换成传设备日志，发现压缩率飙升到60%以上，说明压缩功能一直正常，只是数据类型不同导致表现差异。
别光盯着数字看，得结合业务来判断。压缩率是个参考值，不是健康度打分卡。只要关键服务运行流畅，没有异常报错，低压缩率未必是病，别自己吓自己。