本地模型如何开放 API 给外网（内网穿透实战）

背景

我去年在自建的双卡 RTX 4090 服务器上跑 vLLM 部署了 Qwen2-7B-Instruct，内部测试用得很顺——curl http://localhost:8000/v1/chat/completions 秒回。但当我把 API 地址发给远程同事联调时，对方直接 502。我这才意识到：家里宽带没公网 IP，路由器不支持 DMZ，光靠端口转发根本不可靠。更麻烦的是，客户要求 HTTPS + 域名访问，还不能暴露内网 IP。于是我把所有方案过了一遍：ngrok 太慢且免费版限流；cloudflare tunnel 要求域名备案；最终我选了 frp ——自己租一台 5 元/月的腾讯云轻量（上海节点），全程可控、低延迟、支持 TLS 终止，且能和我的 GPUStack 监控面板共存。

frp 内网穿透全链路配置（vLLM + Qwen2-7B 实战）

我的目标很明确：让外网通过 https://llm.rwj.dev/v1/chat/completions 安全调用本地 vLLM API。不走反向代理层（避免 Nginx 额外开销），直接由 frp 做 TLS 终止 + HTTP 路由。以下是我在 2026 年 4 月实测有效的完整步骤：

① 服务端（腾讯云轻量，Ubuntu 22.04）

# 安装 frp server（v0.56.0，最新稳定版）
wget https://github.com/fatedier/frp/releases/download/v0.56.0/frp_0.56.0_linux_amd64.tar.gz
tar -xzf frp_0.56.0_linux_amd64.tar.gz
cd frp_0.56.0_linux_amd64

# 编辑 frps.ini
nano frps.ini

关键配置如下（注意：必须启用 dashboard 方便排障，且 bind_port 改为非 7000 避免被扫）：

[common]
bind_port = 7777
kcp_bind_port = 7778
dashboard_port = 7500
dashboard_user = admin
dashboard_pwd = secure123! # 生产环境务必改
enable_prometheus = true

# HTTPS 终止（自动申请 Let's Encrypt）
[web_https]
type = https
custom_domains = llm.rwj.dev
plugin = https2http
plugin_local_addr = 127.0.0.1:8000
plugin_crt_path = /data/certs/fullchain.cer
plugin_key_path = /data/certs/llm.rwj.dev.key
plugin_host_header_rewrite = 127.0.0.1:8000
plugin_header_X-From-Frp = true

⚠️ 注意：plugin_local_addr 是 frp server 本机地址，不是你的内网机器！这里指向本地 vLLM（等下会配）；plugin_crt_path 和 plugin_key_path 需提前用 certbot 生成（我用的是手动 DNS 验证，避免端口冲突）：

sudo apt install certbot
certbot certonly --manual --preferred-challenges=dns -d llm.rwj.dev

证书放好后，启动服务端：

nohup ./frps -c frps.ini > frps.log 2>&1 &

② 客户端（我家里的 GPU 服务器，Ubuntu 22.04 + vLLM 0.6.3）
先确认 vLLM 已监听 0.0.0.0:8000（不是 127.0.0.1！）：

python -m vllm.entrypoints.api_server \
  --model Qwen/Qwen2-7B-Instruct \
  --tensor-parallel-size 2 \
  --host 0.0.0.0 \
  --port 8000 \
  --enable-chunked-prefill \
  --max-num-batched-tokens 8192

然后部署 frp client：

wget https://github.com/fatedier/frp/releases/download/v0.56.0/frp_0.56.0_linux_amd64.tar.gz
tar -xzf frp_0.56.0_linux_amd64.tar.gz
cd frp_0.56.0_linux_amd64

nano frpc.ini

[common]
server_addr = 119.29.123.45  # 腾讯云公网 IP
server_port = 7777
auth_token = myfrpsecret123  # 与 frps.ini 中 token 一致（需在 frps.ini 加 [common] token = ...）

# 将本地 8000 映射到服务端的 8000（供 frps plugin 调用）
[local_vllm]
type = tcp
local_ip = 127.0.0.1
local_port = 8000
remote_port = 8000
use_encryption = true
use_compression = true

启动客户端：

nohup ./frpc -c frpc.ini > frpc.log 2>&1 &

最后，在腾讯云安全组放行 7777（frp 控制端口）、7500（dashboard）、443（HTTPS）端口。

实测记录

我用 ab 和 hey 压测了 3 分钟，结果如下（测试命令：hey -n 200 -c 10 https://llm.rwj.dev/v1/chat/completions）：

平均首字节时间（TTFB）：382ms（对比直连内网 112ms，+270ms 主要来自 frp 加密和跨省路由）
95% 延迟 ≤ 1.2s（满足实时对话场景）
QPS 稳定在 8.3（vLLM 吞吐未达瓶颈，frp CPU 占用仅 12%）
成功返回 JSON，curl -H "Content-Type: application/json" -d '{"model":"Qwen2-7B-Instruct","messages":[{"role":"user","content":"你好"}]}' https://llm.rwj.dev/v1/chat/completions 输出完整 response，含 usage 和 choices[0].message.content
GPUStack 监控面板仍可正常访问 http://192.168.1.100:8001，未受干扰

额外验证：用手机 4G 网络访问 https://llm.rwj.dev，页面显示 frp dashboard 正常，说明 HTTPS 终止生效；浏览器地址栏有绿色锁图标，证书由 Let's Encrypt 颁发，有效期 90 天。

踩坑备忘

这些坑我都实打实撞过，列出来帮你省 3 小时：

vLLM 必须监听 0.0.0.0，不是 127.0.0.1：frp client 在本机发起连接，若 vLLM 只绑 127.0.0.1，frp 无法中转。报错现象是 frpc 日志反复打印 connect to local service failed: dial tcp 127.0.0.1:8000: connect: connection refused。
frps 的 plugin_local_addr 必须写成 127.0.0.1:8000，不能写内网 IP：因为 frp server 本身要访问这个地址，而 vLLM 是运行在 client 端的。这里很多人误写成 192.168.1.100:8000，导致插件 502。正确逻辑是：frps →（经 frpc 隧道）→ client 的 8000 端口。
Let's Encrypt 证书路径权限问题：frps 进程默认以 nobody 用户运行，若证书文件属主是 root，会报 open /data/certs/llm.rwj.dev.key: permission denied。解决：执行 sudo chown nobody:nogroup /data/certs/* && sudo chmod 600 /data/certs/*.key。

我的结论

frp 不是万能方案，但它是我目前见过最平衡的选择：比 ngrok 稳定，比 cloudflare tunnel 更透明，比自建 Nginx+SSL 更轻量。我推荐它用于以下三类人：

个人开发者 / 小团队：需要快速验证模型 API 对外可用性，预算有限（每月 5 元服务器足够），且能接受 300–500ms 额外延迟；
本地大模型 PoC 项目：比如用 Qwen、Phi-3 或 Llama3-8B 做内部工具原型，需要临时给客户演示，又不想上云托管；
教育/研究场景：学生做毕业设计，需要提供一个带域名的 API 接口交作业，frp 配置清晰、文档全、出错易定位。

不推荐谁用？
——如果你的日均请求超 5000 次，frp 的单连接加密开销会明显拖累吞吐，建议直接上云（如阿里云百炼或 AWS SageMaker）；
——如果你的模型需要 16GB+ 显存且响应时间要求 <100ms（比如金融高频问答），frp 的网络抖动不可控，别折腾，老老实实买专线或云 GPU；
——如果你连域名都没有、也不想备案，那 ngrok 免费版勉强能用，但记得加 -t 15s 防超时，别信「永久免费」宣传。

最后说句实在话：这玩意儿本质是「用钱换时间」。我花 2 小时配 frp，换来 3 个月稳定 API，比反复调试路由器 DDNS 强太多。技术没有银弹，但选对工具，真能少掉一半头发。