FRP 与 NPS 穿透技术深度解析:通信端口、流量链路与最佳实践

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

标签: 

正在查看 2 条回复
  • 作者
    帖子
    • #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

    • #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 + 缓存,减少带宽压力。

    • #818

      追光
      管理员

      公网 Nginx 反向代理 对性能和速度的影响简要总结如下


      影响分析

      1. 增加一次 TCP 转发

        • 用户 → Nginx(80/443)

        • Nginx → FRPS(8080)

          额外的网络跳转会带来 微秒到毫秒级延迟,通常在 0.1~2ms(同机)或 1~5ms(跨机)。

      2. HTTPS 终止开销

        • 如果 SSL 在 Nginx 终止,Nginx 会处理加解密,增加 CPU 开销,但现代 CPU 和 OpenSSL 优化下,影响极小(约 1%~3%)。

      3. 吞吐影响

        • 单次请求的额外代理处理极轻量,Nginx 是高性能反代,性能瓶颈几乎不会出现在这一层。

        • 在高并发(>10万QPS)下,反代可能增加 少量 CPU 消耗,但仍比大多数应用后端快。


      正面作用

      • 性能优化

        • 开启 HTTP/2、gzip、缓存,反而可能 提升整体速度(尤其静态资源)。

      • 安全加固

        • 防御 DDoS/WAF、隐藏真实端口,提升系统稳定性。

      • SSL 卸载

        • 把 SSL 工作交给 Nginx,FRP 隧道走纯 HTTP,减少加解密负担。


      一句话总结

      公网 Nginx 反代带来的延迟影响可以忽略(通常 <5ms),但可以显著提高安全性和可扩展性,开启缓存甚至能提升整体性能。

正在查看 2 条回复
  • 在下方一键注册,登录后就可以回复啦。