通义千问1.5-1.8B-Chat-GPTQ-Int4 WebUI企业内网部署：内网穿透方案与安全访问配置

最近帮几个团队部署了通义千问的轻量级模型，发现一个挺普遍的需求：模型明明部署在公司内网的服务器上跑得好好的，但开发、测试或者远程协作的同事就是没法直接访问。要么得连VPN，要么得跑到服务器跟前去操作，实在不方便。

这其实就是典型的企业内网部署场景。模型和数据都放在内部，安全是保证了，但可用性打了折扣。今天咱们就来聊聊，怎么用内网穿透这个“桥梁”，既能让外部的授权人员方便地访问到内网的模型WebUI，又能把安全的大门守好，不让无关人员进来。

1. 为什么企业内网部署后，还需要外部访问？

你可能觉得，模型部署在内网服务器上，内部人员直接访问不就行了？但在实际工作里，情况往往更复杂。

想象一下这些场景：公司的算法工程师在办公室的服务器上部署并调试好了模型，但产品经理在家办公，想看看模型的实际对话效果；或者测试团队需要从外网环境进行压力测试；又或者，你们为某个客户定制了一个服务，需要让对方在保证数据不出他们网络的前提下，临时访问你们内网的演示环境。

这些情况都指向同一个需求：如何安全、可控地将一个内网服务“临时”或“长期”地开放给外部特定人员访问。直接暴露服务器公网IP是极不安全的，而让所有人连VPN又过于笨重且权限过大。这时候，内网穿透就提供了一个折中且优雅的解决方案。

它的核心思路是，在内网服务器和一台拥有公网IP的中转服务器（也叫“跳板机”或“穿透服务器”）之间，建立一条加密的通道。外部用户访问中转服务器的某个端口，请求就会通过这条通道转发到内网服务器的WebUI服务上，响应再原路返回。对用户来说，他好像直接访问了一个公网服务；但实际上，你的模型和数据依然安稳地待在内网里。

2. 内网穿透方案选型与快速部署

市面上内网穿透的工具不少，开源的比如frp、ngrok，商业化的也有各种云服务商提供的产品。考虑到企业环境对可控性和安全性的高要求，这里我们重点介绍 frp，因为它开源、灵活、配置透明，非常适合自行掌控。

2.1 方案核心：frp的工作原理

你可以把frp理解为一个“服务转发中介”。它包含两个核心组件：

• frps (Server)：部署在具有公网IP的服务器上（比如一台云主机）。它像是一个总机接线员，监听来自公网的访问，并管理所有内网客户端的连接。
• frpc (Client)：部署在你内网的服务器上（也就是运行通义千问WebUI的那台机器）。它主动连接到frps，告诉frps：“我这里有服务，请把发到你某个端口的请求，都转给我。”

当外部用户想访问WebUI时，他访问的是 公网IP:frps端口。frps收到请求后，通过之前建立好的通道，转发给内网的frpc，frpc再交给本机的WebUI服务（比如127.0.0.1:7860）处理。整个过程，数据在公网段是加密传输的，你的内网IP和端口始终没有直接暴露。

2.2 动手部署：十分钟搭建通道

假设你已经在一台云主机（假设IP为 1.2.3.4）和公司内网服务器上分别准备好了Linux环境。

第一步：在公网服务器部署 frps

1. 去frp的GitHub发布页下载对应系统的最新版本压缩包。
2. 解压后，编辑 frps.toml 配置文件（frp新版本推荐使用TOML格式）：

# frps.toml
bindPort = 7000  # frps监听的端口，用于与frpc建立控制连接
auth.method = "token"
auth.token = "your_strong_password_here"  # 设置一个强密码，用于客户端认证

# 可选：Web管理面板，方便查看连接状态
webServer.addr = "0.0.0.0"
webServer.port = 7500
webServer.user = "admin"
webServer.password = "another_strong_password"

3. 启动frps服务：

./frps -c ./frps.toml

建议使用systemd或supervisor将其配置为后台服务，保证持续运行。

第二步：在内网服务器部署 frpc 并连接 WebUI

1. 同样下载并解压frp客户端。
2. 编辑 frpc.toml 配置文件：

# frpc.toml
serverAddr = "1.2.3.4"  # 你的公网服务器IP
serverPort = 7000        # 对应frps的bindPort
auth.method = "token"
auth.token = "your_strong_password_here"  # 必须与frps配置的token一致

[[proxies]]
name = "qwen-webui"
type = "tcp"
localIP = "127.0.0.1"
localPort = 7860         # 通义千问WebUI默认运行的端口
remotePort = 7080        # 在公网服务器上暴露的端口。外部用户将通过 1.2.3.4:7080 访问

这里的配置意思是：将内网 127.0.0.1:7860 的服务，映射到公网服务器的 7080 端口。

3. 启动frpc客户端：

./frpc -c ./frpc.toml

第三步：验证访问

完成以上步骤后，让处于外网的同事，在浏览器访问 http://1.2.3.4:7080。如果一切顺利，他应该能看到你内网服务器上的通义千问WebUI登录界面了。

到这一步，基础的穿透就完成了。但这只是“通了”，离“安全”还差得远。任何知道这个地址的人都能访问，这显然不行。

3. 构筑安全防线：从通道到权限

内网穿透打开了通道，安全配置则是守门的卫士。我们需要层层设防，确保只有合法用户才能使用服务。

3.1 第一道门：WebUI自身的访问控制

很多WebUI框架（如Gradio）支持基本的HTTP认证。在启动通义千问WebUI时，可以加上用户名和密码参数。例如，如果你使用类似launch.py的脚本，可以寻找设置auth参数的选项。这相当于给WebUI加了一把锁。

3.2 第二道门：frp层面的安全加固

仅靠WebUI的密码不够，我们可以在frp层面增加更多控制：

1. 强Token认证：前面配置里已经用了token，务必使用高强度、无规律的字符串，避免被猜测。

2. 限制代理绑定IP：在frps配置中，可以为每个代理设置 bindAddr，将其绑定到127.0.0.1，这样公网IP上的其他端口扫描将看不到服务。但通常我们通过防火墙来实现更灵活的控制。

3. 使用STCP模式（推荐）：上述的TCP模式是端口映射，知道公网端口的人都能尝试连接。frp的 STCP (Secret TCP) 模式更安全。它要求访问者也需要运行一个特定的frpc（访问者客户端），并持有相同的访问密钥才能建立连接。

   配置STCP模式：

   • frps配置：无需特殊改动。
   • 内网frpc配置：

   [[proxies]]
   name = "qwen-webui-secure"
   type = "stcp"
   secretKey = "a_shared_secret_key"  # 定义一个共享密钥
   localIP = "127.0.0.1"
   localPort = 7860
   

   • 访问者机器配置：

   [[visitors]]
   name = "qwen-visitor"
   type = "stcp"
   serverName = "qwen-webui-secure"  # 对应内网代理的name
   secretKey = "a_shared_secret_key"  # 相同的密钥
   bindAddr = "127.0.0.1"
   bindPort = 8989  # 访问者本地监听的端口
   

   访问者启动此frpc后，在本地访问 http://127.0.0.1:8989，流量就会通过frps安全地转发到内网服务。这样，服务完全不暴露在公网端口上。

3.3 第三道门：网络防火墙与云安全组

这是至关重要的一环。在你的公网服务器（云主机）上，必须严格配置防火墙（如iptables）或云服务商的安全组规则。

• 原则：最小化开放。只开放frps必需的端口（如上述的7000控制端口，以及7500管理面板端口），对于为TCP模式映射的业务端口（如7080），除非必要，否则不应该在公网防火墙层面开放。对于STCP模式，则完全不需要开放额外的业务端口。
• 使用IP白名单：如果某些合作方有固定IP，可以在安全组规则中设置，仅允许来自这些特定IP地址的流量访问frps的端口。这是非常有效的防护手段。

3.4 第四道门：API访问与密钥管理

如果外部系统需要通过API调用你的模型，而不是使用WebUI，那么API密钥（API Key）认证就是标配。

• 在启动通义千问的API服务器时（如果框架支持），务必配置 api_key 参数。
• 所有API请求必须在Header中携带正确的 Authorization: Bearer 或类似的密钥字段。
• 密钥要定期轮换，并通过安全的渠道分发给授权用户或系统。
• 在frp服务器或内网服务器层面，可以部署轻量级的反向代理（如Nginx），对 /api 路径的请求增加一层基于Token的认证，实现双因素验证。

4. 一个完整的实践案例：为远程团队开放测试环境

假设你为“A团队”部署了一个定制化的通义千问模型，用于内部知识库问答。A团队成员分布在不同城市，需要远程访问。

你的操作流程可能是这样的：

1. 部署：在内网服务器192.168.1.100上部署好模型和WebUI，运行在7860端口。
2. 规划：申请一台云主机作为跳板机（1.2.3.4）。决定采用最安全的 STCP模式。
3. 配置frps：在云主机上配置并运行frps，开放7000端口。
4. 配置内网frpc：在内网服务器配置STCP代理，secretKey设置为 teamA_test_key_2024q3。
5. 制作访问包：为A团队的每个成员生成一个简单的 frpc_visitor.toml 配置文件，其中包含上述密钥和云主机地址。你可以将这个配置文件打包在一个简单的启动脚本里。
6. 分发与访问：团队成员拿到包后，运行脚本启动visitor，本地端口绑定到9999。然后他们在浏览器访问 http://127.0.0.1:9999，即可使用内网的WebUI。
7. 安全闭环：云主机安全组只允许A团队办公网IP段访问7000端口。一个月后，更换secretKey并重新分发。

这套流程下来，数据流始终在加密通道中，没有暴露任何公网业务端口，访问权限通过密钥和IP白名单双重控制，达到了企业级的安全要求。

5. 总结

把通义千问这样的模型部署在内网，再通过内网穿透安全地开放出去，听起来有点绕，但确实是平衡安全与便利的实用方法。frp这样的工具给了我们很大的灵活性，关键是要理解不同模式（TCP、STCP）的安全差异，并愿意花时间在访问控制、防火墙和密钥管理这些“琐事”上。

实际用下来，STCP模式虽然需要每个访问者都运行客户端，稍微麻烦一点，但安全感是实实在在的。对于固定的小团队或合作伙伴，这种方式非常合适。如果是对接不确定的公网用户，可能就需要在TCP模式的基础上，结合更强大的反向代理（如Nginx）来做HTTPS、限流和复杂的认证了。

安全是一个过程，不是一次配置。定期审查日志、轮换密钥、更新组件版本，这些好习惯能让你的内网模型服务既好用，又让人放心。

---

获取更多AI镜像

想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。