FRP 与 NPS 穿透技术深度解析:通信端口、流量链路与最佳实践
› VFX大学 › Linux/macOS 与自动化运维 › FRP 与 NPS 穿透技术深度解析:通信端口、流量链路与最佳实践
标签: frp穿透

-
作者帖子
-
-
2025年7月20日 - 下午11:38 #811
追光管理员FRP真实通信信息链路的流量路径分析,涵盖 协议、端口、作用,并补充 请求、响应、加密/压缩情况,适用场景:内网穿透、Web 服务发布、远程访问、实时传输优化。
为什么要理解通信链路?
在使用 FRP(Fast Reverse Proxy)和 NPS(Nginx Proxy Service)做内网穿透时,很多人会混淆:
-
外部访问端口和隧道传输端口的区别。
-
FRP/NPS 究竟通过哪个通道传输数据?
-
TCP 和 KCP 的选择对性能的影响?
理解清楚这些,可以帮助我们 优化架构、提高性能、排查问题。
完整链路解析(FRP HTTP 场景)
假设:
-
外部用户访问 http://example.com
-
FRPS 服务器在公网(IP:X.X.X.X)
-
内网有一台机器运行 Nginx(127.0.0.1:80)
-
FRPC 在内网运行,负责隧道
详细链路
[ 用户浏览器 ] │ │ (HTTP 请求) ←协议: TCP 80 ▼ [ 公网 IP:80 (FRPS vhost_http_port) ] │ │ (请求通过 FRPS) │ ▼ [ FRPS ] │ │ (通过隧道将 HTTP 数据封装) │ 绑定端口: 7000 │ 协议: TCP (默认) 或 KCP (UDP) │ 可选: 压缩、加密 │ ▼ [ FRPC ] │ │ (解封装后转发) │ 协议: TCP → 内网请求 │ ▼ [ 本地服务:127.0.0.1:80 (Nginx) ] │ │ (处理请求,返回 HTML/数据) │ ▼ [ FRPC ] → 封装响应 → [ FRPS ] → 通过隧道返回 → [ 用户浏览器 ]
✅
关键点解析
环节
协议/端口
作用
用户 → FRPS
HTTP / TCP 80
外部请求入口
FRPS → FRPC
TCP 7000 / UDP KCP
真实数据传输隧道
FRPC → 本地服务
TCP 80
将请求送到内网服务(Nginx)
响应回传
同上隧道
数据封装后返回用户
✔ 所有穿透流量都走 FRPC ↔ FRPS 的长连接(bind_port),外部端口只是入口。
✅
增强版链路图(带协议 & 可选优化)
[ 用户浏览器 ] │ │ TCP:80 (HTTP 请求) ▼ [ FRPS : vhost_http_port = 80 ] │ │ (封装请求) │ ▼ [ FRPS ←→ FRPC ] 隧道: - 控制 & 数据: TCP bind_port=7000 (or KCP UDP) - 可选: use_compression=true - 可选: use_encryption=true │ ▼ [ FRPC → 内网服务 ] TCP:80 → Nginx
✅
可选优化点
-
多链路分流:HTML/JS/CSS 开压缩,视频链路关闭压缩。
-
KCP 传输:提高弱网下速度(需开放 UDP)。
-
Nginx 缓存 + gzip:优化静态资源。
✅
对应 FRP 配置示例
FRPS
bind_port = 7000 vhost_http_port = 80 dashboard_port = 7500
FRPC
server_addr = your-frps-ip server_port = 7000 type = http local_port = 80 custom_domains = example.com use_compression = true
-
-
2025年7月20日 - 下午11:43 #815
追光管理员当 公网 FRPS 暴露的端口不是 80/443,而内网本地服务仍然是 80/443 时,链路依然是通过 FRPS 的 remote_port 或 vhost_http_port 进行入口 → 隧道转发 → FRPC 转发到本地端口。
跳转不是“HTTP 重定向”,而是 FRP 隧道层转发。而为了去掉端口号,我们一般都用nginx做反向代理,链路如下:用户 → 公网Nginx (80/443) → 反代到 FRPS (8080) → 隧道 → FRPC → 内网服务 (80/443)
这种情况下,链路多了一层 公网 Nginx 反向代理,它的作用是 接管标准端口 80/443,让用户无感知地访问网站。
✅
完整流量链路(详细)
[ 用户浏览器 ] │ │ TCP:80 (HTTP 请求) 或 TCP:443 (HTTPS 请求) ▼ [ 公网 Nginx ] │ │ (反代到 FRPS 8080) │ proxy_pass http://127.0.0.1:8080; ▼ [ FRPS ] │ │ (通过 bind_port = 7000 隧道发送给 FRPC) │ ▼ [ FRPC ] │ │ (转发到内网服务 127.0.0.1:80) ▼ [ Nginx 内网服务 ]
✔ 从用户角度:访问域名不带端口(80/443),但实际上 FRPS 监听的是 8080,通过反代隐藏了端口差异。
✅
这个链路的特点
-
公网 80/443 由外部 Nginx 接管,你可以加:
-
SSL(HTTPS 证书)
-
WAF(安全防护)
-
HTTP/2、缓存
-
-
FRPS 无需直接占用 80/443,避免与其他服务冲突。
-
FRP 仍然用隧道传输(控制通道 bind_port),公网 Nginx 只是入口代理。
✅
配置要点
公网 Nginx 反代配置
server { listen 80; server_name example.com; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }
FRPS 配置
[common] bind_port = 7000 vhost_http_port = 8080
FRPC 配置
[common] server_addr = x.x.x.x server_port = 7000 [web] type = http local_port = 80 custom_domains = example.com
✅
链路性能注意点
-
额外一层 Nginx 反代会增加 一次 TCP 握手,但性能损耗非常低。
-
如果使用 HTTPS,建议 SSL 终止在公网 Nginx,FRPS 和 FRPC 之间走纯 HTTP,减少加解密负担。
-
可以开启 Nginx 的 gzip + 缓存,减少带宽压力。
-
-
2025年7月20日 - 下午11:47 #818
追光管理员公网 Nginx 反向代理 对性能和速度的影响简要总结如下:
✅ 影响分析
-
增加一次 TCP 转发
-
用户 → Nginx(80/443)
-
Nginx → FRPS(8080)
额外的网络跳转会带来 微秒到毫秒级延迟,通常在 0.1~2ms(同机)或 1~5ms(跨机)。
-
-
HTTPS 终止开销
-
如果 SSL 在 Nginx 终止,Nginx 会处理加解密,增加 CPU 开销,但现代 CPU 和 OpenSSL 优化下,影响极小(约 1%~3%)。
-
-
吞吐影响
-
单次请求的额外代理处理极轻量,Nginx 是高性能反代,性能瓶颈几乎不会出现在这一层。
-
在高并发(>10万QPS)下,反代可能增加 少量 CPU 消耗,但仍比大多数应用后端快。
-
✅ 正面作用
-
性能优化:
-
开启 HTTP/2、gzip、缓存,反而可能 提升整体速度(尤其静态资源)。
-
-
安全加固:
-
防御 DDoS/WAF、隐藏真实端口,提升系统稳定性。
-
-
SSL 卸载:
-
把 SSL 工作交给 Nginx,FRP 隧道走纯 HTTP,减少加解密负担。
-
✅ 一句话总结
公网 Nginx 反代带来的延迟影响可以忽略(通常 <5ms),但可以显著提高安全性和可扩展性,开启缓存甚至能提升整体性能。
-
-
-
作者帖子
- 在下方一键注册,登录后就可以回复啦。