SUPER COLORIZER内网穿透部署：让本地模型服务拥有公网访问能力-程序员充电站

SUPER COLORIZER内网穿透部署：让本地模型服务拥有公网访问能力

你是不是也遇到过这样的烦恼？在本地电脑上好不容易部署好了SUPER COLORIZER这个强大的图片上色模型，效果惊艳，想分享给同事看看，或者想在手机上测试一下，结果发现——别人根本访问不了你的本地服务。

这就像你精心准备了一桌好菜，却只能自己关起门来品尝。本地部署的模型服务，天生就困在“内网”这个小圈子里，没有公网IP，外部设备根本无法直接连接。今天，我就来手把手教你，如何给你的SUPER COLORIZER模型服务“开一扇窗”，让它拥有公网访问能力，实现远程演示、移动端测试和团队协作自由。

整个过程并不复杂，核心就是利用“内网穿透”技术。简单来说，它就像请了一位住在公网上的“邮差”。你在本地跑服务，这位邮差在公网有个固定地址（域名）。当外部用户访问这个公网地址时，邮差就会把请求“穿透”到你的内网，交给你的本地服务处理，再把结果“穿透”回去。这样，你的本地服务就“假装”自己有了一个公网身份。

1. 准备工作：理清思路与备好工具

在开始动手之前，我们先花几分钟，把整个流程和需要的东西理清楚。这能帮你避免过程中手忙脚乱。

1.1 理解我们的目标架构

想象一下我们最终要实现的效果：

你的本地电脑：正常启动SUPER COLORIZER服务，假设它运行在http://localhost:7860（这是Gradio的默认端口）。
公网上的“邮差”（穿透客户端）：在你的电脑上运行一个轻量级程序，它会主动连接到一个拥有公网IP的服务器（穿透服务端）。
公网上的“邮局”（穿透服务端）：通常由服务商提供，它有一个固定的域名（比如your-name.example.com）和公网IP。
外部访问者：在手机、同事的电脑上，直接访问http://your-name.example.com。
数据流转：访问请求先到“邮局”，再通过已建立的通道转发给你的“邮差”，最终送达本地的SUPER COLORIZER服务。响应则按原路返回。

整个过程对你本地的SUPER COLORIZER服务是透明的，它完全不知道自己正在被公网访问。

1.2 你需要准备什么

一个正常运行的SUPER COLORIZER本地服务：这是前提。确保你能在浏览器通过http://127.0.0.1:7860正常访问它的Web界面。
一台拥有公网IP的服务器（VPS）：这是“邮局”的所在地。你可以从各大云服务商（如阿里云、腾讯云、AWS等）购买最基础的VPS即可，通常选择Linux系统（如Ubuntu）。
一个域名（可选但推荐）：虽然可以直接用服务器IP访问，但域名更易记、更专业。你可以注册一个新域名，或者使用服务商提供的免费子域名。
基本的命令行操作能力：需要在服务器和本地电脑上执行一些简单的命令。

市面上有很多现成的内网穿透工具和服务，为了让你理解原理并拥有最大控制权，本教程选择使用frp这款开源、高性能的反向代理工具。它分为服务端和客户端，我们需要分别在服务器和本地电脑上配置。

2. 第一步：在服务器上部署frp服务端

“邮局”需要先搭建好。登录到你购买的云服务器。

2.1 下载并安装frp

通过SSH连接到你的服务器。我们以Linux系统为例。

首先，去frp的GitHub发布页面查看最新版本号，然后用wget命令下载。假设最新版本是0.54.0。

# 创建一个目录存放frp mkdir -p /opt/frp cd /opt/frp # 下载frp压缩包（请将版本号替换为最新） wget https://github.com/fatedier/frp/releases/download/v0.54.0/frp_0.54.0_linux_amd64.tar.gz # 解压 tar -zxvf frp_0.54.0_linux_amd64.tar.gz # 进入解压后的目录，这里目录名会随版本变化 cd frp_0.54.0_linux_amd64

解压后你会看到很多文件，其中frps和frps.ini是服务端需要的。

2.2 配置frp服务端

我们需要编辑frps.ini配置文件。

# 使用nano或vim编辑配置文件 nano frps.ini

将文件内容修改为如下示例。这里设置了认证令牌（token）以增加安全性，并指定了服务端监听的端口。

[common] # frp服务端监听的端口，客户端用来连接的端口 bind_port = 7000 # 认证令牌，客户端需要配置相同的才能连接，请务必修改成一个复杂的字符串 token = your_secure_token_here # 仪表板端口，用于查看连接状态（可选） dashboard_port = 7500 # 仪表板用户名和密码（可选） dashboard_user = admin dashboard_pwd = admin_password_here # 日志记录（可选） log_file = ./frps.log log_level = info log_max_days = 3

保存并退出编辑器。请务必将token和dashboard_pwd替换为你自己的强密码。

2.3 启动并设置开机自启

首先，直接启动测试一下：

./frps -c ./frps.ini

如果看到类似“frps started successfully”的日志，说明服务端启动成功。按Ctrl+C停止。

为了让服务在后台持续运行并在服务器重启后自动启动，我们使用 systemd 来管理。

创建一个systemd服务文件：

sudo nano /etc/systemd/system/frps.service

写入以下内容（注意修改ExecStart的路径为你实际的frps路径）：

[Unit] Description=Frp Server Service After=network.target [Service] Type=simple User=nobody Restart=on-failure RestartSec=5s ExecStart=/opt/frp/frp_0.54.0_linux_amd64/frps -c /opt/frp/frp_0.54.0_linux_amd64/frps.ini [Install] WantedBy=multi-user.target

保存后，启用并启动服务：

# 重新加载systemd配置 sudo systemctl daemon-reload # 设置开机自启 sudo systemctl enable frps # 启动frps服务 sudo systemctl start frps # 查看服务状态 sudo systemctl status frps

看到active (running)就说明服务器端的“邮局”已经搭建完毕，在7000端口等待“邮差”来连接了。

重要安全提醒：别忘了在你的云服务器控制台的安全组（或防火墙）设置中，放行7000端口（frp连接用）和7500端口（仪表板用，如果开了的话）。

3. 第二步：在本地电脑配置frp客户端

现在，我们来配置你本地电脑上的“邮差”。

3.1 下载本地frp客户端

根据你的本地电脑操作系统，去frp的GitHub发布页面下载对应的客户端。如果是Windows，就下载windows_amd64版本；如果是Mac，下载darwin_amd64版本。

这里以Windows为例，下载后解压到一个方便的目录，比如D:\frp。

3.2 配置frp客户端

在解压目录中找到frpc.ini文件，用文本编辑器打开。

我们需要配置两部分：一是连接服务器的信息，二是定义具体的穿透规则。

[common] # 你的服务器公网IP地址或域名 server_addr = your_server_ip_or_domain # 服务器上frps监听的端口，我们之前设置的是7000 server_port = 7000 # 必须和服务器frps.ini中配置的token一致 token = your_secure_token_here # 定义一个名为“super-colorizer-web”的穿透规则 [super-colorizer-web] type = tcp # 本地服务的IP，通常是127.0.0.1 local_ip = 127.0.0.1 # 本地SUPER COLORIZER服务的端口，默认是7860 local_port = 7860 # 远程端口：这是服务端开放出来用于公网访问的端口。 # 外部用户将通过 server_addr:remote_port 来访问。 # 确保这个端口在服务器防火墙是放行的。 remote_port = 6000

配置说明：

server_addr：填写你云服务器的公网IP。如果你有域名并解析到了这个IP，也可以填域名。
token：必须和服务器端设置的一模一样。
[super-colorizer-web]：这是一个规则名称，可以自定义。
remote_port：这里设置为6000。意味着外部用户访问http://你的服务器IP:6000时，流量就会被转发到你本地的7860端口。

3.3 启动客户端连接

打开命令行（CMD或PowerShell），进入frp客户端所在目录，执行：

frpc.exe -c frpc.ini

如果连接成功，你会看到类似“start proxy success”和“login to server success”的提示。同时，在服务器的frps日志里（可以通过sudo journalctl -u frps -f查看），也应该能看到客户端连接上来的日志。

现在，最核心的穿透已经完成了！你可以让朋友尝试访问http://你的服务器IP:6000，理论上应该能看到你本地的SUPER COLORIZER界面了。

4. 第三步：进阶配置与优化

直接用IP加端口访问虽然能用，但不够友好，也不安全。我们来做一些优化。

4.1 使用域名访问（更友好）

直接记IP和端口号很麻烦。我们可以用域名。

域名解析：在你的域名管理后台，添加一条A记录，将你喜欢的子域名（例如colorizer.yourdomain.com）指向你的云服务器公网IP。
修改客户端配置：将server_addr改为你的域名。
配置HTTP穿透（可选）：上面的配置是TCP穿透，直接转发端口。如果你想用80或443端口（默认HTTP/HTTPS端口），让用户直接访问http://colorizer.yourdomain.com而不用加端口号，需要修改穿透类型。

将客户端配置中的规则部分修改为：

[super-colorizer-web-http] type = http local_ip = 127.0.0.1 local_port = 7860 # 自定义域名 custom_domains = colorizer.yourdomain.com # 如果你希望用HTTPS，还需要配置https相关的选项，并确保服务器端443端口开放且frps配置支持。

同时，服务器端的frps配置需要添加vhost_http_port选项：

[common] bind_port = 7000 token = your_secure_token_here # 添加这行，指定HTTP反向代理监听的端口，通常是80 vhost_http_port = 80

这样配置后，访问http://colorizer.yourdomain.com的流量，就会被转发到本地服务。

4.2 设置访问密码（更安全）

直接将模型服务暴露在公网，可能会被陌生人随意使用，消耗你的本地资源。Gradio本身支持简单的页面认证。

在启动SUPER COLORIZER时（或者修改其启动脚本），可以加上认证参数。具体方法取决于你启动SUPER COLORIZER的方式。如果是Python脚本，通常可以这样：

python app.py --share --auth username:password

或者，如果你使用的是Gradio的launch函数，可以传递auth参数。设置后，访问Web界面时就需要输入用户名和密码了。

4.3 保持客户端稳定运行

你不能总是开着命令行窗口。在Windows上，可以写一个批处理脚本（.bat）并加入开机启动项，或者使用nssm这类工具将frpc注册为系统服务。在Mac/Linux上，则可以使用launchd或systemd（类似于我们之前在服务器上的操作）。

5. 实际测试与问题排查

配置完成后，一定要进行完整测试。

本地测试：确保http://127.0.0.1:7860能正常访问SUPER COLORIZER。
服务器端测试：在服务器上执行sudo systemctl status frps，确保服务是active状态。
客户端测试：启动frpc客户端，观察日志有无报错（如连接失败、token错误）。
公网访问测试：用你的手机（切换为移动网络，确保不在同一个Wi-Fi下），或者请外地的朋友，访问你设置好的公网地址（IP:端口或域名）。
功能测试：在公网环境下，上传一张图片，测试SUPER COLORIZER的上色功能是否正常工作。

常见问题排查：

连接失败：检查服务器安全组/防火墙是否放行了7000（服务端口）和6000（或你设置的remote_port）端口。检查客户端配置中的server_addr和token是否正确。
能连接但访问不了服务：检查客户端配置中的local_port是否确实是SUPER COLORIZER运行的端口。检查本地防火墙是否阻止了外部连接（对于frpc来说，本地连接是允许的）。
速度慢：内网穿透的延迟和速度受限于你的本地网络上传带宽和云服务器的带宽。如果图片较大，生成过程可能会感觉较慢，这是正常现象。

走完这一套流程，你的本地SUPER COLORIZER就成功“走出深闺”，拥有了公网访问能力。无论是给客户做远程演示，还是在外面用手机随时测试效果，或者和团队成员协作评审，都变得非常方便。

整个过程的核心就是理解“内网穿透”这个“邮差”的角色，然后按部就班地配置好服务器端和客户端。虽然涉及服务器操作，但每一步命令我都给出了详细的示例，跟着做下来应该不难。安全方面，一定要记得设置强密码（token）和考虑Web界面认证，避免服务被滥用。

这种部署方式特别适合开发测试、临时演示或者小团队内部使用。它避免了将模型直接部署到云服务器可能产生的复杂环境和资源消耗问题，让你能充分利用本地强大的计算资源（尤其是GPU），同时又能享受公网访问的便利。下次再遇到需要分享本地AI服务的场景，不妨试试这个方法。