FRP vs NPS 内网穿透部署Web和开放本地端口实践应用后的总结

VFX大学 Linux/macOS 与自动化运维 FRP vs NPS 内网穿透部署Web和开放本地端口实践应用后的总结

标签: 

正在查看 2 条回复
  • 作者
    帖子
    • #756

      追光
      管理员

      这几天一直在使用FPS部署本地服务器,在FRP与NPS的选择之间产生了很大的冲突,到底用哪个?哪个更好,起初俩个都安装了并投入实际应用,逐渐在应用中将俩个的优势区分开来,俩个都用并相互依存,于是在这里写个日志,重新整理架构逻辑。


      日志记录:FRP vs NPS 最佳实践方案(增强版)

      总结核心观点

      1. FRP 适合用于 Web 服务场景

        • 特点:配置后无需频繁修改,稳定运行(黑洞模式)。

        • 强项:

          • 内置域名路由(customDomains)。

          • HTTP/HTTPS(vhost_http_portvhost_https_port)。

          • 多站点 + TLS 管理。

        • 应用:WordPress、多站点、Docker 面板。

      2. NPS 适合用于动态端口通信场景

        • 特点:无需重启即可动态添加/删除转发。

        • 强项:

          • 临时端口转发(AI 服务、数据库、SSH)。

          • Web UI 管理,适合开发调试。

        • 应用:LM Studio、Qdrant、Postgres、SSH。

      3. 两者都支持通过 Nginx 做反向代理

        • 适用场景:

          • 多服务共享一个端口(如 80 或 443)。

          • 提供额外的缓存、WAF、负载均衡能力。

        • 架构:

          • 公网访问 → Nginx → FRP/NPS 隧道 → 内网目标服务。


      架构策略

      • FRP(Web 服务)

        • 处理公网 HTTP/HTTPS,核心用途是站点发布。

        • 配置固定,适合部署生产环境。

        • 可结合 Nginx 进行流量分发。

      • NPS(动态服务)

        • 管理研发端口,临时访问服务。

        • 灵活度高,支持即时修改,不重启服务。

        • 可结合 Nginx 提供统一入口。


      安全原则

      • FRP

        • 启用 token 认证。

        • 使用 HTTPS(vhost_https_port)。

      • NPS

        • 设置强密码 + 管理权限。

        • 临时隧道配置超时,防止暴露。


      文字思维导图

      整体架构
      │
      ├─ FRP(黑洞模式)
      │    ├─ 接管公网 80/443
      │    ├─ 内置域名路由 → Web 服务
      │    ├─ 可配合 Nginx 做二次反代
      │    └─ 应用:
      │         ├─ WordPress
      │         └─ Docker 面板
      │
      ├─ NPS(动态模式)
      │    ├─ 动态端口隧道
      │    ├─ 可配合 Nginx 做入口整合
      │    └─ 应用:
      │         ├─ LM Studio
      │         ├─ Qdrant
      │         └─ SSH
      │
      └─ 公共特性
           ├─ 可接入 Nginx
           └─ 提供统一 TLS、缓存、WAF


      连接图(a–b–web风格)

      公网请求
         ├─> Nginx (可选)
         │      ├─> FRPS (80/443)
         │      │       └─> FRPC → 内网 Web 服务
         │      │                ├─ WordPress
         │      │                └─ Docker 面板
         │      │
         │      └─> NPS
         │              └─> 内网动态服务
         │                     ├─ LM Studio
         │                     ├─ Qdrant
         │                     └─ SSH

    • #761

      追光
      管理员

      补充记录:
      商业型服务器部署中,如果通过 公网 Nginx → FRPS → 本地服务,会带来额外复杂性和性能开销,原因是:
      Nginx 并非纯转发,而是:
      接收请求(完成 TLS、解析 header)
      再处理(反向代理规则、可能涉及 rewrite、缓冲)
      再转发给 FRPS
      这比直接让 FRPS 接管 80/443 多了一层应用处理,增加延迟和维护成本。

      当然我已经做了许多新参数的配置,让nginx实现电线的功能,仅仅只做通讯的转发与连接,但配置相对复杂。所以想要简单快,就直接用frps接管80 443端口,并且在frpc中开启转发真实ip,

      transport.proxyProtocolVersion = "v2"

      最后在本地服务器上的nginx中开启接收frp转发的真实ip即可。

          listen 80 proxy_protocol;
          listen 443 ssl http2 proxy_protocol;
          # 开启 Proxy Protocol 支持
          set_real_ip_from 0.0.0.0/0;
          real_ip_header proxy_protocol;
          # 开启 Proxy Protocol 支持

      结论:
      如果需求仅是端口穿透和域名路由,直接让 FRPS 接管 80/443 是最简单高效的方案。
      Nginx 仅在需要 WAF、安全规则、缓存、负载均衡时才必要。

    • #774

      追光
      管理员

      记录个人感受,总结如下:

      FRP vs NPS 实用区别(个人体验)
      FRP:断网后恢复连接速度非常快,通常 1 秒内完成重连,表现稳定。

      NPS:断网后重连需要较长时间,大约 10 秒左右 才能恢复,延迟明显高于 FRP。

      对于需要 高实时性、SLA 严格、用户体验敏感 的商业场景,FRP 显然优于 NPS。
      NPS 更适用于 内网办公、低频维护 等非实时业务,但如果强行用于高实时业务,需要深度优化。

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