从本地到公网：Stable Diffusion WebUI内网穿透实战指南

自打本地部署了Stable Diffusion WebUI，生成图的质量确实是上来了，可控性也比在线平台强很多。但玩了一段时间就发现一个很现实的问题：这套工具被“锁”在了自己的电脑里，人在办公室、在咖啡厅、在外面出差，或者手机平板上想临时改个参数出一张图，就完全没法用。尤其是想给朋友或者同事炫耀一下成果的时候，总不能把整台电脑搬过去。

这篇文章解决的就是这个“最后一公里”的问题：怎么把跑在内网的Stable Diffusion WebUI安全、稳定地暴露到公网上，让你随时随地打开浏览器就能玩AI绘画。内容会从方案选型讲起，带你走过WebUI本身的配置调整、内网穿透服务的部署细节，再到安全加固和移动端适配。不管你是纯新手还是有一定基础，只要照着操作，就能把自己那套绘画服务真正盘活。

1. 先想清楚：你要的“打通内网”到底是什么

1.1 自建AI绘画服务的“最后一公里”痛点

先说说为什么会有“打通内网”这个需求。大多数人的Stable Diffusion WebUI都是装在本地电脑上的，这是最稳妥、最省钱的折腾方式。WebUI启动后默认监听的地址是127.0.0.1:7860，访问入口只在你这台机器上。也就是说，只有在这台电脑前打开浏览器才能用。

局域网内其他设备想访问都需要手动加参数，而到了局域网之外就彻底没戏了。这里的核心痛点有两个层面：一个是“物理限制”，局域网本身没有公网入口，外部设备找不到这台电脑；另一个是“地址限制”，就算你有公网IP，也不可能直接把内网机器的端口直接映射出去，因为大多数家庭宽带或者公司网络压根没有公网IP，就算有，路由器端口映射也不是人人都会配。

所以，我们要做的事情本质上是：让外部网络能够主动找到并访问内网里的WebUI服务。这才叫真正打通。

这个需求看起来非常简单，但做起来有不少坑。比如WebUI默认不开启监听、防火墙挡端口、隧道服务超时断连、开放公网却被别人扫到端口甚至被刷爆，这些都是实际会遇到的问题。下面所有操作都围绕这些事情展开。

1.2 方案选型：三条“走出去”的路各有优劣

对于“把内网服务暴露出去”这件事，业内成熟的方案其实就三类：路由器端口映射、内网穿透工具、组网工具。作为个人博主的经验分享，我会先给你一张对比表，再详细展开我推荐的那条路。

先说结论：如果你是个人玩，并且希望稳定长期使用，我建议走“内网穿透工具”这条路。为什么不是端口映射？因为绝大多数家庭宽带有IPv4公网地址的概率已经很低了，IPv6虽然有，但需要路由器、防火墙、WebUI本身三端都支持IPv6访问，配置起来反而更麻烦。至于组网工具，适合几个人之间共用，但稳定性和速度受制于服务商，免费版往往还有设备数限制。

而内网穿透工具的核心思路很简单：你不需要外部主动连进来，而是让内网电脑主动“拨号”连到一台公网服务器上，在这台服务器上开一个端口，谁访问这个公网端口，数据就通过这条隧道转给你内网的WebUI。注意，这里是合法的、你自己可控的服务器中转，跟那些非法通道完全两回事。

这个方案唯一需要额外花成本的，是一台公网服务器和一点点配置功夫。它带来的回报是长期稳定、不依赖他人、可定制性强，尤其适合把WebUI长期挂机使用的人。

2. 开工前准备：WebUI服务端配置与网络摸底

2.1 让WebUI监听正确的地址，这一步漏了就全白搭

很多人第一次尝试远程访问，配置了半天隧道，结果打开公网地址还是提示“拒绝连接”。排查到最后才发现，WebUI自己就没监听公网接口。

Stable Diffusion WebUI默认只监听本机回环地址（127.0.0.1），这相当于把门锁死在了房间里。想让外部设备通过隧道访问，必须让WebUI监听在“所有网络接口”上。具体做法是，在启动WebUI的终端里加上 --listen 参数，例如：

./webui.sh --listen --port 7860

如果你是在Windows上用启动器（比如某整合包），通常可以在启动参数设置里找到“监听地址”或者“--listen”的开关，手动勾选保存即可。

加上 --listen 之后，WebUI会监听在0.0.0.0:7860，也就是说本机局域网内的其他设备已经可以通过类似 “http://192.168.1.10:7860” 这样的地址访问了。这一步验证非常关键——如果局域网内部都打不开，那隧道通了你照样打不开。所以我建议在配置远程访问之前，先拿着手机连上同一个Wi-Fi，访问一下电脑的局域网IP加端口，确认服务本身没问题。

2.2 网络环境摸底：记下你的内网IP、确认防火墙放行

在开始部署隧道之前，你最好先把几个基本信息摸清楚：

• 你的电脑在内网的IP，比如 192.168.1.10；
• WebUI监听的端口，比如 7860；
• 内网IP是否固定，如果电脑重启IP会变，建议在路由器里做DHCP地址绑定，或者直接用IP绑定的方式固定下来；
• 电脑本机防火墙是否放行了7860端口。

我见过不少人跳过防火墙这一步，导致局域网内也连不上。Windows系统默认会对“非信任网络”弹一个防火墙授权窗口，很多人直接点了取消，后面就再也进来了。如果你已经遇到过这种情况，可以手动在“允许应用通过防火墙”里把WebUI的Python进程或相关端口加进去。

实际上，在你使用内网穿透的时候，隧道工具是主动从内网往外发起连接的，所以方向上不存在“入站连接被拦截”的问题。但是WebUI监听在0.0.0.0之后，局域网内其他设备访问你7860端口时就属于入站流量，防火墙依然可能拦截。为了简化问题，把本机防火墙的入站规则对7860端口放行，或者至少对Python解释器放行，是最省事的做法。

2.3 账号认证和基础防护：千万不能让裸奔的WebUI直接上公网

这一步经常被新手忽略，却偏偏是最重要的一步。WebUI本身默认是不带密码保护的，任何能访问到你公网地址的人，都能直接打开页面、填入提示词、蹦出一堆图，还能读取你下载过的模型，甚至通过某些功能执行脚本。所以在你做任何“对外开放”操作之前，必须先把基础账号认证打开。

常见做法是给WebUI加上 --gradio-auth 参数：

./webui.sh --listen --port 7860 --gradio-auth 你自己的用户名:你自己的密码

加了之后，打开页面会先弹出一个浏览器登录框，输入用户名密码才能进入。这个功能依托的是Gradio自身的HTTP Basic认证，虽然不算太高级，但对于个人使用场景已经足够挡住绝大多数路人。

我还有一个小建议：密码别用简单组合。因为一旦你暴露了公网地址，必然会被各类扫描器扫到。扫描器会尝试常见的弱口令，如果密码是admin或者123456，那等于大门敞开。

此外，如果你对安全要求更高，可以再引入一层反向代理，用域名加HTTPS来提供访问，这会在后面的“实操”部分详细讲。这里先把第一步“不要裸奔”落实了。

3. 核心实操：走一条安全可靠的内网穿透路线

3.1 准备工作：一台有公网IP的服务器

前面方案选型里说了，内网穿透需要一台公网服务器做“中转站”。这台服务器不需要太高配置，因为真正跑AI绘画的是你本地那台电脑，服务器只负责转发数据流。从费用角度考虑，一台1核1G的入门级云服务器完全够用，带宽通常有1M到5M，用于页面操作和单张图片生成已经足够。

为什么要额外买云服务器而不是直接用免费的中转工具？核心原因是可控性。中转工具帮你省了服务器钱，但服务器地址、端口、域名都不归你把控，免费额度、速度和稳定性也是全看运气。自建隧道虽然要花一点点小钱，但链路完全在你手里，出问题可以自己排查，数据也不会经过第三方中转服务。如果你愿意签个长期套餐，成本其实很低，而且可以用很多年。

买完之后，你会拿到一个公网IP和SSH登录方式。记下这个IP，后面配置中要用到。这里我用示例IP 203.0.113.10来做演示，实际使用的时候替换成你自己的服务器地址。

3.2 服务端配置：frps开一个“接待处”

有了服务器，接下来要做的就是在服务器上部署隧道服务的“服务端”。我用的比较多的是frp这一类开源反向代理工具，它体积小、配置简单、生态成熟，非常适合个人自建穿透。

先登到服务器上，下载frp对应系统架构的压缩包并解压。服务器端我们关注的就是 frps 这个程序和 frps.toml 配置文件。以较新版本的配置格式为例，服务端配置可以这样写：

bindPort = 7000 auth.token = "你自己定义的一长串随机字符串"

这里 bindPort 就是隧道服务端的监听端口，未来内网客户端要连过来都用这个端口。auth.token 相当于内网客户端连上来时输入的“口令”，用来防止别人蹭你的隧道。建议用一段足够长的随机字符串，比如带大小写和数字的十六位以上字符。

启动它：

./frps -c frps.toml

如果一切正常，终端里会出现服务端监听的相关日志。此时你要记得在云服务器的安全组、防火墙规则里放行7000端口，否则外部连不上。这一步很多人会忘记，导致后面客户端一直连不上，排查半天发现是安全组没放行。

然后，你需要再放行一个后续给WebUI访问使用的公网端口，我习惯用7810或者直接复用7860，但为了不冲突以及安全性考虑，用7810作为对外访问端口会更清晰。

3.3 客户端部署：frpc拨号回连

服务端准备好了，接下来是内网电脑上的客户端配置。下载frp客户端（frpc），在配置文件里写上服务器地址、通信口令、以及要暴露的内网服务信息。示例配置如下：

serverAddr = "203.0.113.10" serverPort = 7000 auth.token = "和你服务端配置一样的随机字符串" [[proxies]] name = "webui" type = "tcp" localIP = "127.0.0.1" localPort = 7860 remotePort = 7810

这段配置的意思是：让这台内网电脑主动连到云服务器的7000端口，然后把本地7860端口的WebUI服务映射到云服务器的7810端口上。也就是说，别人只要访问 203.0.113.10:7810，就能通过隧道到达你本地电脑上的WebUI。

启动客户端：

./frpc -c frpc.toml

看到类似“login to server success”的日志，就说明隧道已经建立。此时你再打开浏览器访问 http://203.0.113.10:7810，应该能看到WebUI的登录框（如果你加了 --gradio-auth）或者直接看到WebUI界面。

3.4 绑定域名与HTTPS：从“能用”到“好用”的关键一步

直接用IP加端口访问，能用是能用，但不优雅。更关键的是，裸奔在HTTP协议下，账号密码和生成过程都是明文传输，在公共Wi-Fi环境里有被窃听的风险。为了让访问更安全、更像个正经服务，我强烈建议你用一个域名加HTTPS来访问。

做法不复杂：你先有一个域名，解析一个子域名（比如 sd.example.com）到你的云服务器公网IP。然后在服务器上用反向代理服务（例如常见Web服务器软件或Caddy这类自动申请证书的工具）把来自443端口的请求转发到本机的7810端口。因为frp客户端已经在本机的7810端口提供服务，所以你只需要在服务器上把某个域名对应443端口的流量转发到127.0.0.1:7810即可。

我比较喜欢用Caddy，因为它的配置非常简洁，而且会自动申请和续期HTTPS证书。比如这样一段配置：

sd.example.com { reverse_proxy 127.0.0.1:7810 }

保存配置并让Caddy加载后，它会自动为这个域名申请证书，然后所有访问 https://sd.example.com 的请求都会被转发到你的隧道入口。这样做的好处有几个：浏览器不会再提示不安全、账号密码在传输过程中被加密、别人一眼看到域名就知道这是你专属的服务。

这里有一个注意点：一旦你用域名和HTTPS访问WebUI，之前在WebUI里加的 --gradio-auth 仍然保留，因为它提供的是HTTP Basic认证，和HTTPS不冲突，相当于多加了一道锁。

3.5 隧道稳定性验证与开机自启

隧道建立起来之后，我们不能只用一次就完事，毕竟目标是“随时随地都能访问”。但内网电脑没准哪天重启了、断电了、系统更新了，服务可能就断了。所以我们需要把frpc做成开机自启服务，确保电脑一开机，隧道就自动连上。

在Windows上，最简单的方式是用任务计划程序创建一个“登录时启动”的任务，或者直接用NSSM这类工具把frpc注册成Windows服务。Linux系统上则可以用systemd服务来管理。核心目标只有一个：让frpc在后台稳定运行，并在异常退出后自动拉起。

打开Windows任务计划程序，创建基本任务，触发器选择“用户登录时”，操作选择“启动程序”，程序路径选到你的frpc.exe，参数填 -c frpc.toml。保存后，下次登录系统就会自动启动隧道。如果是长期挂机的电脑，建议把“设置”里的“不管用户是否登录都要运行”也选上，这样不需要手动登录也能维持服务。

同理，云服务器端的frps也需要设置开机自启。在Linux上写一个systemd service单元文件，然后enable起来，这样即使服务器重启，隧道服务也会自动恢复。

到这里，“通”的问题已经彻底解决了。外网设备访问域名就能打开WebUI，隧道稳定运行，且链路安全。

4. 使用体验优化与疑难杂症排查

4.1 手机和平板端：WebUI也能触屏操作

远程访问打通后，我在手机上试了一下，发现直接打开桌面版WebUI在触屏设备上有些别扭——按钮太小，参数滑块不好拖，鼠标悬停才能看到的工具提示也看不到。这里有几个提升体验的技巧：

• 浏览器菜单里选择“请求桌面网站”，优先加载完整界面；
• 如果只是刷手机看看出图效果，可以开WebUI自带的“生成预览”功能，它会把历史生成结果列在界面上，方便快速查看；
• 手机上输入提示词时，建议把常用提示词保存为预设或样式，减少打字量；
• 如果觉得界面太挤，可以把浏览器页面放大或缩小，Chrome移动版支持页面缩放，桌面版内核也支持触控拖拽。

另外要注意，移动网络访问时，上传的图片和下载的图片都要经过隧道中转，流量消耗会比想象中大。如果是普通套餐云服务器，大图来回传输可能有点慢，建议生成时把图像分辨率调低一些，或者在服务器端加上图片压缩类插件。

4.2 共享给朋友时的使用习惯

打通内网之后，我最常做的事就是扔一个链接给朋友，让他在自己手机上看我出的图和做好的LoRA。但这里有个坑：如果朋友和你不在同一个网络，他访问的就是你的公网域名，所有流量都经过你的云服务器。如果服务器带宽只有1M，图片加载会非常慢，甚至可能卡死。

我的建议是，如果要给朋友展示，提前把生成的图片存成一个作品集页面，或者直接用WebUI的快捷分享功能生成短链接，而不要让他实时跑到你本地服务上慢慢翻。如果是几个人协作，还应该考虑同时在线对服务性能的影响——WebUI生成图片是计算密集型任务，同一时间多人提交任务，GPU会扛不住。

我自己会在服务器端做一个简单的访问控制，比如只在需要展示的时间段内开启隧道，平时默认关闭，避免非预期流量攻击和资源浪费。也可以用WebUI前面加的一层代理来实现来源IP白名单，允许家庭或公司IP直接访问，其他IP一律拒绝。

4.3 常见问题与排查方向速查表

在配置和长期使用的过程中，我遇到过不少问题，这里整理成一张速查表，方便你对照排查。

我的经验是，百分之六十的“打不开”问题都出在网络放行上，剩下的才是配置写错。所以遇到问题先按照“本机能不能开 → 局域网能不能开 → 公网能不能开”的顺序逐层排查，往往几分钟就能定位。

4.4 安全加固清单与长期运维建议

前面说过不要让WebUI裸奔，但安全这件事一次做完还不够，长期运维时要养成几个习惯：

• 定期更换frp的auth.token，尤其是在你怀疑配置泄露之后；
• 保持frp和WebUI相关软件更新，避免已知安全漏洞；
• 云服务器安全组只对必要的端口开放，例如7000只对客户端开放、7810/443只对真实来源开放；
• 如果长期开放访问，建议在服务器上加一个简单的日志分析和访问频率限制，防止有人暴力破解或恶意刷请求；
• WebUI本身可能出现不安全的第三方插件，不要盲目安装来路不明的插件和模型，尤其在对外开放时。

我个人的习惯是给WebUI跑在一个专用系统用户下，权限尽量缩小，目录和文件权限不要随意放开。这样即使出现安全问题，影响范围也被限制在可控范围内。

另外，长期挂机会产生大量图片文件，建议定期备份模型和Lora配置，图片素材按天归档到移动硬盘或网盘。云端服务器只是转发节点，不会存你的生成记录，所以本地备份就是唯一保障。

结尾

我在给朋友搭建这套远程访问方案时，最大的体会是：别急着一步到位追求“完美”，先跑通最小可用链路最关键。很多时候你觉得自己卡在隧道配置上，实际上卡在WebUI监听参数上；你觉得是服务器问题，其实是防火墙没放行。只要把链条一个个环节拆开验证，问题都能定位到具体某一层。

最后分享一个小技巧：把WebUI的启动命令、frpc的启动命令都写成一个批处理或脚本，并输出详细日志。每次遇到问题，先看日志，基本能解决九成以上的事情。日志不会骗人，比你凭感觉猜要高效得多。这套方案我已经稳定跑了几个月，出差在外、躺在床上都能随时掏出手机看一眼生成的图，那种“工具终于完全属于自己”的感觉，如果你也喜欢折腾，非常值得自己动手试一次。