最近有几个朋友问我同一个问题：自己电脑上装好了 Stable Diffusion WebUI，生成效果也不错，但人一离开工位就啥都干不了，手机上也看不到进度、没法远程跑图。尤其是上班摸鱼或者出差的时候，想临时改个参数、追加几张图，非得跑回电脑前。这个问题说大不大，说小也不小——本质上就是一件事：怎么把一个跑在本地局域网里的 AI 绘画服务，安全、稳定地暴露到公网上，让你人在外面也能随时调用。
我花了两天时间把这条链路完整打通了，从方案选型、实际配置到踩坑修复都走了一遍。这篇文章就把整个实践过程拆开讲清楚，适合已经能本地跑起 Stable Diffusion WebUI、但还没搞定远程访问的人。看完之后，你不仅能照抄我的配置，还能理解每一步为什么这么设计，遇到问题也能自己排查。
1. 方案选型：为什么我放弃了“想当然”的做法
先别急着上工具，这一步想清楚，后面能省一大半的折腾时间。远程访问本地服务，市面上大概有四条路：公网直连、内网穿透、异地组网、反向代理配合认证。我用排除法一个一个过。
1.1 公网直连：看着简单，坑最多
很多人第一反应是“我家宽带不是有公网 IP 吗，直接映射端口不就行了”。理论上确实可以，但实操起来劝退率极高。首先是很多地区的宽带默认不给你公网 IPv4，运营商的大内网里你的 IP 是个保留地址，外网根本摸不到。就算你打电话申请到了公网 IP，家里的光猫、路由器还要做端口映射、动态 DNS 解析，中间任何一环配置错，服务就起不来。更关键的是，Stable Diffusion WebUI 本身只带了一个简单的账号密码验证，把它直接挂到公网上等于把自己的算力资源裸奔——别人扫描到端口就能试着撞库，撞进去就能白嫖你的显卡，严重一点还可能被拿去挖矿。
我在本地用 netstat 看过 WebUI 默认监听地址，就是 127.0.0.1:7860，这个地址只有本机能访问。要让局域网内的其他设备能访问，得先改监听参数，改成 0.0.0.0:7860。但就算改成这样，也只是局域网能通，离“随时随地”还差着十万八千里。
1.2 内网穿透：方便但不够“稳”
内网穿透的思路是，你本地主动连一个公网服务器，由那台服务器帮你转发流量。这种方案不需要公网 IP，也不需要路由器配置，装个客户端就完事。市面上的花生壳、frp、natapp 都属于这一类。
这类方案最大的问题是速度和质量取决于中转服务器的带宽和位置。免费档的服务器带宽小，传一张 1024x1024 的图可能都要卡半天；付费档又要把流量绕到别人的机房，延迟多少会有点影响。而且如果服务商出问题，你的访问就跟着一起挂。对于偶尔应急够用，但作为长期方案心里没底。
我最终没有选 frp 作为主力方案，还有一个原因：它需要自己维护一台公网 VPS。虽然 frp 性能好、可控性强，但服务器的安全加固、frps 服务端配置、域名备案这些事情都要自己管，对只想“随时随地玩 AI 绘画”的人来说负担太重了。
1.3 异地组网：体验最接近“内网”的方案
异地组网的意思，是把你的手机、笔记本和你家里的电脑拉进同一个虚拟局域网里，让它们好像真的在一个 WiFi 下一样，直接通过内网 IP 访问服务。这个方案不需要公网 IP、不需要路由器改配置、不用装服务端，直接装客户端软件，登录同一个账号就能互相访问，体验和一直在家里局域网没什么区别。
这个方案还有一个特别实用的点：一定能穿透 NAT，也不依赖服务器转发具体流量——只要打洞成功，数据就直连了。这意味着速度的上限很高，跑满你的上行带宽没问题，传图、加载模型都快。
所以我最后就定了这个方向：用异地组网把设备连进同一个虚拟局域网，然后用原始的内网 IP 来访问 WebUI。等这套通了之后，我又顺手把公网访问也走了一遍，作为备用方案，这个后面细说。
1.4 安全边界：远程访问之前先想清楚的事
不管你选哪种方案，有一件事必须提前想明白：Stable Diffusion WebUI 是你的个人工具，不是公共服务。它暴露的范围越广，被攻击的风险就越大。就算用了组网方案，也只建议把你自己的手机、笔记本加进网络，不要把链接发给一堆人共享。
远程访问这件事，我的安全底线是三句话：能不加账号就不加账号，能用私有网络就不用公网，能不暴露端口就不暴露端口。组网方案在这一点上天然占优——它压根不开任何公网端口，外部扫描器面对你是“隐身”的。
2. 核心原理：WebUI 的网络参数和监听逻辑
在动手配置之前，我建议你先搞清楚 Stable Diffusion WebUI 的启动参数到底在干什么。这决定了你后面遇到问题时的排查方向。
2.1 几个关键启动参数的含义
WebUI 的启动参数里，和网络访问直接相关的有这几个：
--listen：让服务监听所有网络接口。不加这个参数，服务只绑定 127.0.0.1，外部设备连不上；加上之后，局域网内其他设备才能通过你的电脑 IP 访问。--port：指定服务端口，默认是 7860。如果被占用了，可以用这个参数换一个。--share：生成一个临时的公网分享链接。这是 WebUI 自带的功能，背后依赖内网穿透服务，但链接有效期有限，且连接质量不太稳定，我一般不把它作为主力方案。--xformers：优化显存和速度，对远程跑图有间接帮助，但不是网络相关参数，这里不展开。
需要特别提醒的是，如果你决定用异地组网方案，--listen这个参数加上之后，WebUI 就不止绑定物理网卡的 IP，还会绑定虚拟网卡的 IP。也就是说，组网里的其他设备也能通过虚拟局域网 IP 来访问。如果你不想让同一局域网里的其他人都能访问，可以稍微把服务绑定到一个具体的 IP 上，比如写成--listen 172.x.x.x，这样它就只监听你指定的那个地址。
2.2 手机和电脑怎么找到 WebUI
WebUI 的访问地址格式简单来说就是“IP 地址 + 端口号”。在局域网里，这个 IP 是你电脑的局域网 IP，可以通过命令查；在组网里，这个 IP 是你的设备在虚拟局域网里的 IP，可以从组网客户端里看到。
我当时第一次配好之后，用手机浏览器去访问电脑的虚拟局域网 IP:7860，结果页面刷不出来。排查了很久才发现，原来 WebUI 还没启动完，日志里还在加载模型，得等它完全 ready 之后端口才会通。这个经验后面会详细说。
2.3 为什么默认只能本机访问
很多人不理解：为什么默认不加--listen就访问不了？这是开发者的安全设计。Stable Diffusion WebUI 默认缺少强认证机制，如果直接暴露到局域网甚至公网，等于把一台免费 GPU 服务器送给了同网的任何人。所以默认只监听回环地址，本机能访问，外部一概拒绝。理解了这一点，你就知道为什么不能直接拿公网 IP 裸奔——不是技术上做不到，是不应该做。
3. 实操流程：组网方案从零到通的完整记录
下面是我实测走过的完整流程。我会写得尽量细，包括每一步的命令、界面操作和踩坑点，照着走基本能一次成功。
3.1 第一步：确认本地服务能跑通
老规矩，先做基础验证。在你电脑上启动 Stable Diffusion WebUI，不带任何额外参数。等命令行里出现Running on local URL: http://127.0.0.1:7860的提示后，本机浏览器打开这个地址，确认能正常出图。
这一步不是多余的——它能确保你的环境、模型、依赖都没问题。我见过有人卡在远程访问，排查半天发现是本地的模型路径写错了，WebUI 一直在报错没起来。
本地确认没问题后，关掉 WebUI，接下来加上--listen参数重新启动。在 webui 的启动脚本里，找到启动命令那一行，在后面追加--listen。以 Windows 系统为例，一般是在 webui-user.bat 里的COMMANDLINE_ARGS变量上加入这个参数。改完保存，重新启动。
启动之后，用局域网里的另一台设备（比如手机连同一个 WiFi）访问http://你的电脑局域网IP:7860，能打开就行。这一步如果不行，优先检查 Windows 防火墙：在“允许应用通过防火墙”里找到 Python，确保专用和公用网络的复选框都勾上了。
3.2 第二步：安装并配置组网客户端
异地组网的客户端软件有很多家，我这里说一个通用流程，具体名字不方便点名，你可以搜“游戏联机用的虚拟局域网工具”就能找到同类产品。这类软件大多支持 Windows、macOS、Android、iOS，注册账号之后，会自动给每台设备分配一个虚拟局域网 IP。
安装完客户端后，在你的电脑和手机上都登录同一账号。电脑端会有一个虚拟网卡，手机端会多一个虚拟 IP。把两台设备加入同一个网络房间（不同软件叫法不一样，有的叫网络，有的叫房间），它们之间就可以互通了。
配置完成后，在电脑端打开命令行，输入ipconfig，你会看到多了一块网卡，它的 IP 段通常和你的物理网卡不一样。记下这个 IP，它就是组网里的“内网 IP”。
3.3 第三步：让 WebUI 监听虚拟网卡并启动
现在回到 Stable Diffusion WebUI。我们刚才已经启动了带--listen参数的版本，理论上它会监听所有网卡，当然也包括虚拟网卡。所以不需要再改什么，直接打开手机浏览器，访问http://你的电脑虚拟局域网IP:7860，就能看到熟悉的界面了。
我实际操作时发现一个细节：如果你之前是用--listen 127.0.0.1这种方式指定的，那么虚拟网卡的 IP 不会被监听。正确做法是直接写--listen不带参数，让它监听所有接口，或者在启动参数里指定虚拟网卡的具体 IP，比如--listen 172.22.0.8:7860。指定 IP 的方式更安全，它只开放虚拟局域网通道，不会让同一物理局域网里所有人都能访问。
3.4 第四步：手机端体验和参数微调
手机浏览器打开 WebUI 界面之后，默认是桌面版网页，操作起来比较费劲，尤其是提示词输入框和参数滑块，手指头点不准。我建议你在手机浏览器里开启“桌面版网站”模式，布局会好很多。或者干脆用平板的浏览器，体验更接近桌面。
如果你想让手机端操作更顺手，可以试一下 SD WebUI 的移动端优化插件，这类插件能把界面重排成卡片式布局，更适合触屏操作。我自己用下来觉得，远程临时调整 prompt、看看生成进度、下载图片，这套组合完全够用。
3.5 实测速度和稳定性记录
我自己的环境是台式机 + 3060Ti，手机走的是 5G 网络。实测下来，从外面发起一张 512x768 的图，提示词大概 60 个词条，生成耗时约 4 秒，但图片从电脑传到手机要 1~2 秒。整体响应速度比直接在电脑前操作慢半拍，但完全在可接受范围内。关键是真的稳定，我从公司、地铁、商场三个场景测过，没有一次连接失败。
如果你是异地组网连不上的情况，优先检查两点：一是客户端是否真的登录成功，二是虚拟网卡是否启用。很多软件会在电脑休眠后把虚拟网卡停掉，重新打开客户端就连上了。
4. 进阶操作：把 WebUI 接入统一入口并加固安全
异地组网方案解决的是“人在外面能连回家”，但如果你有多个本地服务都想远程访问，每次记一堆 IP 和端口就麻烦了。我实践下来，有几个进阶操作值得做。
4.1 给手机加书签和快捷方式
手机浏览器里把http://虚拟IP:7860加为书签，放到桌面，以后点击图标就能直达 WebUI，省去每次输地址。iPhone 可以用“添加到主屏幕”，Android 是在浏览器菜单里选“添加到主屏幕”，效果类似一个原生 App 图标。
4.2 用反向代理统一入口管理多个服务
如果你家里还跑了其他的本地 Web 服务，比如文件管理面板、代码仓库、监控面板，可以通过局域网内的一台 Nginx 反向代理，把不同路径转发到不同端口。比如http://虚拟IP/sd转发到 7860，http://虚拟IP/files转发到 5000。这样整个入口地址只需记一个。
Nginx 的配置最关键的部分是这段：
server { listen 80; server_name 虚拟IP; location /sd { proxy_pass http://127.0.0.1:7860; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }注意proxy_pass后面不要加路径，否则会丢失路径参数。我一开始就是在这里踩了坑，配完之后访问/sd直接 404。
4.3 给 WebUI 加上登录认证
前面说过，WebUI 默认没有登录认证。好在它自带了一个--gradio-auth参数，格式是“用户名:密码”。在启动命令里加上：
--gradio-auth username:password这样任何人访问界面时都需要先登录。密码建议用长一点的随机字符串，别用生日和手机号。如果你用的是最新版本的 WebUI，也可能支持多个账号，用逗号分隔配置即可。
这里多说一句：--gradio-auth是 Gradio 框架自带的能力，Stable Diffusion WebUI 直接继承了过来。密码在网络传输中是明文还是加密，取决于你是用 HTTP 还是 HTTPS 访问。如果在组网环境里用 HTTP，密码理论上能被同一网络里的人看到。所以有条件的话，建议在 Nginx 层挂一个自签名的 HTTPS 证书，或者直接用组网软件的加密特性，不要裸跑明文密码。
4.4 限制访问来源设备
如果你用的是组网方案，客户端后台通常可以管理网络里的成员，把不需要的设备移除，或者设置仅允许指定设备加入。这一步也值得做——防止你的设备被别的人加进同一个网络里。
5. 常见问题与排查技巧实录
这部分是我这几天踩坑的总结。有些问题网上教程不太会写，但实际遇到概率很高，建议先存着备用。
5.1 WebUI 能打开但一直转圈显示空白
大概率是 WebUI 没有完全启动。它加载大模型的时候，HTTP 服务其实已经起来了，但界面要等模型加载完才正常可用。这个过程可能需要几十秒甚至一分钟。解决办法就是等，或者看电脑端的日志输出有没有到达Startup time那一行。
5.2 手机能访问 IP 但画面特别模糊
这个不是网络问题，是 WebUI 界面在手机上默认缩放了。点开浏览器菜单，选“请求桌面版网站”，画面就变清楚了。如果你用平板，一般会自动展示桌面布局，问题不大。
5.3 组网客户端显示已连接，但 WebUI 打不开
先确认你访问的 IP 对不对。组网客户端里显示的虚拟 IP，和电脑ipconfig里看到的虚拟网卡 IP 应该一致。如果不一致，以客户端显示的为准。还有一种情况是虚拟网卡没拿到 IP，重新禁用再启用这块网卡，或者重启客户端。
5.4 防火墙弹出 Python 网络访问请求
Windows 防火墙会弹窗问你“是否允许 Python 访问网络”，一定点允许。如果之前手抖点了取消，去“防火墙和网络保护”里把 Python 的入站规则打开，或者直接重新运行 WebUI 再点允许。
5.5 WebUI 端口被占用
有时候电脑上其他服务占用了 7860 端口，WebUI 起不来。换个端口，用--port 7861指定新的端口，访问时也改成对应端口。注意先确认一下端口确定没被别的关键服务占用。
5.6 排查思路速查表
| 现象 | 优先排查 | 解决方案 |
|---|---|---|
| 手机打不开 WebUI | 是否加了--listen参数 | 启动参数中添加--listen |
| 组网里找不到设备 | 客户端是否登录同账号并加同网络 | 重新登录客户端，检查网络名 |
| 网页一直转圈 | WebUI 是否加载完模型 | 看电脑日志，等启动完成 |
| 画面模糊 | 浏览器是否桌面模式 | 浏览器里选桌面版网站 |
| 端口被占用 | 7860 是否被其他进程占用 | 换--port 7861重新启动 |
| 访问很慢 | 手机网络和上行带宽 | 确认 5G/WiFi 质量，检查电脑上行 |
6. 最终实现效果与经验总结
整套流程走完之后，我的日常使用场景变成了这样：下班路上手机连上组网，打开书签直接进 WebUI，改两个参数，提交生成任务，回到家图片已经躺在输出文件夹里了。在公司午休时也能掏出手机跑一张测试图，看看新模型搭配某个 LoRA 的效果，不用等到晚上回家再试。
我个人的体会是，远程访问 Stable Diffusion WebUI 这件事，技术和配置只是第一层，真正决定体验的是三个细节：走本地中转不走公网中转、WebUI 启动参数要设计好、模型加载完成前别急着刷新页面。把这三个点搞清楚，其他问题基本都是顺带的。
目前这套组网方案已经在我的设备上稳定跑了两个星期，没掉过链子。后续如果想更进一步，可以考虑把 WebUI 放进 Docker 里跑宿主机上的独立网络地址，或者把模型管理、LoRA 下载这些操作也做成手机端能一键完成。不过这些都是后话了，先把这一步打通的体验，确实让人有点回不去坐在电脑前慢慢调参的日子了。
