Midjourney 用什么 VPN，不能只看网页能否打开。它的主要交互发生在 Discord：客户端需要持续接收频道事件，向机器人提交指令，上传参考图，再从内容分发网络取回预览图与成品。线路即使可以完成登录，也可能在 WebSocket 长连接、图片回传或出口切换时出现问题。选择标准因此不是单一峰值速度，而是连接连续性、上下行表现、出口稳定性与客户端分流是否正确。
实际判断可以拆成几个可观察环节：Discord 是否能保持在线状态，指令是否及时出现确认，生成进度是否连续更新，图片缩略图与原图是否完整加载，切换频道后是否需要反复重连。只要其中一个环节不稳定，使用体验就会表现为“能打开，但不好用”。
Midjourney 为什么比普通网页更挑线路
普通网页访问通常是一组相对短暂的请求。页面资源加载结束后，即使线路短时波动，用户也未必立刻察觉。Discord 则需要维持持续会话。客户端通过网关接收新消息、状态变化和交互结果，Midjourney 的任务回执也依赖这条事件通道。连接中断后，客户端虽然会尝试恢复，但恢复过程可能造成进度停住、消息延迟出现或界面看似在线却没有更新。
WebSocket 长连接不是简单的网页加载
WebSocket 建立后会长期存在，期间需要正常收发心跳与事件。线路抖动、代理进程休眠、网络切换或中间设备回收空闲连接，都可能迫使会话重新建立。这里最重要的不是某次测速跑得多快，而是连续传输期间是否频繁丢包、重传或断开。
协议名称也不能直接代表实际结果。VMess、VLESS 与 Trojan 常见于基于 TCP、WebSocket 或其他传输方式的配置；Shadowsocks 的实现相对直接，但表现仍由加密方式、服务器负载和传输路径共同决定。Hysteria2 与 TUIC 建立在 QUIC 与 UDP 能力之上，在存在抖动或丢包的网络里可能更灵活，但前提是当前网络没有明显限制 UDP。若 UDP 路径质量差，协议理论上的优势不会自动转化为稳定体验。
图片上传与回传考验双向链路
文字指令本身数据量很小，但参考图上传、预览图显示和成品下载会调用不同的内容域名。线路若只有下行表现尚可，而上行不稳定，上传参考图时仍可能长时间停住。反过来，网关在线并不表示图片节点也已正确经过代理；分流规则漏掉内容域名时，常见现象就是消息正常、图片空白。
| 交互环节 | 主要连接特征 | 线路异常表现 | 判断方法 |
|---|---|---|---|
| Discord 登录与频道加载 | HTTPS 请求与账户会话建立 | 页面停留在加载状态，频道列表不完整 | 检查出口地区、DNS 结果与系统时间 |
| 频道事件与任务回执 | WebSocket 持续连接 | 消息延迟出现，进度长时间不刷新 | 观察客户端是否反复重连，切换线路后再提交测试任务 |
| 参考图上传 | 持续上行与内容域名访问 | 上传进度停顿，附件发送失败 | 使用相同文件对比不同线路，排除文件本身问题 |
| 预览图与成品回传 | 图片内容分发网络下载 | 缩略图空白，原图打开缓慢或中断 | 检查内容域名是否被分流规则遗漏 |
| 交互按钮操作 | 事件通道与接口请求共同参与 | 按钮已点击但迟迟没有回执 | 确认网关仍在线，并查看客户端连接日志 |
直连、中转与 IEPL 专线怎么比较
线路类型描述的是数据从本地到出口节点所经过的路径。直连线路由本地网络直接访问境外服务器，结构简单，性能受公网路由影响较大。中转线路先接入较近的入口，再由中转网络送往出口，通常可以避开一部分不理想的公网路径。IEPL 专线强调跨境段的专用承载方式，目标是减少公网路由变化带来的波动，但最终体验仍取决于本地接入、入口质量、出口负载与服务端配置。
因此，“专线”不等于所有地点、所有时段都必然最快，“直连”也不等于一定不可用。Midjourney 更看重持续会话与双向传输，选择时应把稳定性放在峰值带宽之前。若直连线路路由简洁且本地运营网络匹配，它可能足够顺畅；若跨境公网波动明显，中转或 IEPL 通常更适合保持 Discord 的事件通道。
| 线路类型 | 路径特点 | 适合情形 | 需要留意 |
|---|---|---|---|
| 直连 | 本地网络直接到达出口服务器 | 公网路由稳定，主要进行文字交互与轻量图片查看 | 不同运营网络与时段的路由变化可能明显 |
| 中转 | 先进入中转入口，再前往目标出口 | 需要改善跨境路径，兼顾频道事件与图片传输 | 入口和出口任一侧拥塞都会影响整体表现 |
| IEPL 专线 | 跨境段采用专用承载路径 | 长时间使用 Discord，频繁上传素材并接收图片 | 仍需检查本地接入、出口地区与客户端协议支持 |
出口地区、DNS 与分流规则
出口地区应保持相对一致。Discord 会结合账户会话、出口网络和设备状态处理连接。短时间内频繁跨地区切换，容易使现有会话失效，也会让图片请求与网关连接落到不同路径。日常使用更适合固定常用地区，仅在线路确实异常时切换，而不是每次启动都随机选择。
地区距离只是参考，不是唯一判断依据。地理位置较近的出口可能拥有较低的传播距离，但若跨境路径拥塞，实际交互仍会不稳定。相反，路径更清晰的中转出口即使地理距离稍远，也可能让 WebSocket 更连续。测试时应保留相同客户端、协议与分流设置，只更换线路，避免同时改变多个条件后无法定位原因。
DNS 泄漏为什么会造成“消息正常、图片失败”
DNS 查询决定域名被解析到哪个地址。如果浏览器或系统绕过代理使用本地 DNS，而实际连接又通过其他地区出口，解析结果与连接路径可能不一致。部分内容域名还会根据解析来源返回不同节点。结果可能是 Discord 主界面正常，而图片内容节点连接缓慢或失败。
处理方式不是简单更换浏览器。应先确认客户端是否启用了代理 DNS 或远程解析，再检查系统的加密 DNS 设置是否与代理客户端冲突。启用系统代理并不必然接管所有 DNS 查询；采用虚拟网卡模式时，也要确认 DNS 流量确实进入对应规则。所谓 DNS 泄漏，在这里主要指查询没有按预期走代理路径，并不代表账户内容已经被公开。
分流规则要覆盖完整服务链路
规则模式常按域名、应用或目标地址决定是否代理。只把 Discord 主域名加入规则，可能漏掉网关、附件、媒体与内容分发域名。规则集过旧时，也可能把新域名送入直连。最稳妥的排查方式是临时使用全局代理确认问题是否消失；若全局模式正常，再回到规则模式查看未命中的连接，而不是长期依赖全局模式掩盖配置缺口。
- ✅ Discord 客户端、浏览器与图片内容请求使用同一稳定出口
- ✅ DNS 查询由代理客户端按预期处理，解析路径与连接出口一致
- ✅ 规则覆盖网关、附件、媒体与内容分发请求，而不只覆盖主页面
- ✅ 系统休眠或网络切换后，确认 Discord 已恢复事件连接
- ❌ 不在任务生成过程中频繁更换出口地区或代理模式
- ❌ 不把一次网页测速结果直接当作长连接质量结论
协议选择：看网络环境，不看名称排序
Shadowsocks、VMess、Trojan、VLESS、Hysteria2 与 TUIC 都可能承载 Discord 流量，但它们不是单独决定体验的标签。客户端实现、传输层、拥塞控制、服务器负载、入口路由和本地网络限制共同决定结果。相同协议放在不同线路上，表现可能比不同协议之间的差异更大。
基于 TCP 的配置
常见的 Shadowsocks、VMess、VLESS 与 Trojan 配置可以使用 TCP 承载。TCP 对网络兼容性较好，适合 UDP 受限的办公网络、公共网络或路由设备环境。Discord 的 WebSocket 本身通常建立在可靠传输之上，因此这类配置容易部署和排查。需要注意的是，当底层连接出现丢包时，重传可能让后续数据等待，表现为消息突然成批出现或图片加载阶段性停顿。
VMess 与 VLESS 是不同的代理协议，Trojan 的流量外观与 TLS 部署相关。是否使用 WebSocket、gRPC 或其他传输方式由具体配置决定，不能看到协议名就推断传输路径。Shadowsocks 也有不同实现与加密方式，客户端是否支持服务端提供的配置必须先确认。
基于 QUIC 与 UDP 的配置
Hysteria2 与 TUIC 侧重使用 QUIC 和 UDP，在高抖动或存在丢包的链路上可以采用更灵活的拥塞控制与多路传输策略。对于图片回传与持续会话，这种特性可能减少某条数据流阻塞其他数据流的情况。但部分网络会限制、整形或直接阻断 UDP，届时客户端可能无法建立连接，或表现得比 TCP 配置更不稳定。
实用做法是同时保留兼容性较好的 TCP 方案与经过验证的 QUIC 方案。当前网络允许 UDP 且线路稳定时，可以比较 Hysteria2 或 TUIC；连接建立失败、频繁回退或公司网络策略较严格时，优先使用可稳定工作的 TCP 配置。协议切换应服务于故障定位，而不是把协议越新等同于体验越好。
订阅导入与各平台客户端差异
订阅链接通常由服务端生成，客户端通过它取得节点名称、地址、协议与必要参数。正确流程是从账户面板复制订阅地址，在客户端的订阅管理中导入并更新，再选择节点连接。不要把订阅链接当作普通网页地址反复在浏览器打开；浏览器显示的一串文本未必适合手工修改，误删参数后可能造成节点无法使用。
- 从服务账户页面复制适用于当前客户端的订阅链接。
- 在客户端订阅管理中选择从链接添加，而不是逐项猜测协议参数。
- 执行订阅更新，确认节点名称与协议已出现在列表中。
- 先选稳定线路建立连接，再打开 Discord 检查频道更新。
- 上传一张可公开测试的素材，检查上传、回执与图片回传。
- 若规则模式异常，临时切换全局模式对照，再检查规则命中情况。
Windows 与 macOS
桌面系统通常同时提供系统代理和虚拟网卡模式。系统代理主要接管遵循系统设置的应用，而部分应用连接可能绕过它；虚拟网卡模式可以覆盖更多流量，但需要正确配置路由与 DNS。Discord 桌面客户端若在系统代理下仍无法稳定加载图片，可以先确认应用是否确实走代理，再决定是否启用虚拟网卡模式。
macOS 对网络扩展权限管理较严格，首次启用虚拟网卡或网络扩展时需要完成系统授权。Windows 上则要留意多个代理客户端同时运行造成的端口、路由或 DNS 冲突。排查时只保留当前使用的客户端，断开后确认系统代理已复原，再进行下一轮测试。
Android 与 iOS
移动系统通常通过系统 VPN 接口接管应用流量。切换无线网络与移动网络、锁屏省电或后台限制，都可能中断现有长连接。重新回到 Discord 后，如果频道消息没有更新，应先等待客户端恢复网关会话；仍无响应时，再断开并重连代理。频繁强制关闭应用并不一定能解决线路问题，反而会增加会话重建。
不同移动客户端支持的协议和订阅格式并不完全相同。导入前应核对客户端是否支持服务端提供的协议，尤其是 Hysteria2、TUIC 以及某些 VLESS 传输组合。若订阅能更新但节点无法连接，优先检查兼容性与系统权限，而不是直接判断节点失效。
一套可复现的 Midjourney 实测方法
线路对比要减少变量。测试期间使用同一设备、同一客户端、同一协议配置与同一网络，只替换节点。不要一边更换线路，一边修改 DNS、分流模式和客户端内核，否则即使结果改善，也无法确认是哪项变化产生作用。
先观察 Discord 自身，再观察 Midjourney。打开常用频道，确认新消息能够连续出现；随后提交普通文字指令，查看机器人是否及时确认；再上传可用于测试的参考图，观察上行是否中断；最后打开生成结果与原图，确认内容域名加载完整。测试过程中切换到其他频道再返回，可以帮助发现事件连接是否已经静默断开。
记录现象，而不是只写“快”或“慢”
有用的记录应描述具体故障，例如“频道消息停止更新，重新连接后一次出现”“文字回执正常，但缩略图空白”“参考图上传停住”“切换网络后客户端未恢复”。这些现象分别指向网关连接、内容域名、上行链路或会话恢复。仅记录主观快慢，无法指导下一步排查。
- ✅ 保持设备、客户端、协议与本地网络不变，只替换测试线路
- ✅ 分别检查频道事件、文字指令、素材上传、预览图和原图
- ✅ 记录断线、重连、空白图片与上传停顿等可复现现象
- ✅ 在规则模式异常时，用全局模式进行短时对照
- ❌ 不用单次下载速度代替 WebSocket 与上行测试
- ❌ 不在同一轮测试中同时修改协议、DNS 和分流规则
常见故障的定位顺序
Discord 能打开，但 Midjourney 没有回执
先确认频道的新消息是否仍在更新。如果所有消息都停住，问题更可能位于 WebSocket 连接；可以查看客户端日志是否发生连接重置或重复重连。若频道消息正常，但机器人交互没有结果，再检查 Discord 服务状态、当前频道权限与任务本身，而不要先认定是带宽不足。
文字正常，图片一直空白
这通常值得检查内容域名分流与 DNS。临时使用全局模式对照，如果图片恢复，说明规则可能遗漏了附件或内容分发请求。若全局模式仍失败，更换同地区的其他线路并清理客户端缓存，判断是出口到内容节点的路径问题，还是本地应用缓存异常。
上传参考图失败
检查上行链路、文件访问权限与代理模式。浏览器可以上传而桌面客户端不能上传时，应比较两个应用是否使用相同代理路径。虚拟网卡模式下还要确认没有其他网络工具同时改写路由。若小型文字交互正常、持续上传中断，则线路上行抖动比峰值下载速度更值得关注。
移动网络切换后不再更新
从无线网络切换到其他网络时，原有连接的本地地址和路径都会变化，WebSocket 必须重新建立。先确认代理客户端已在新网络完成连接，再回到 Discord 等待会话恢复。如果界面仍保持旧状态，可以重新进入频道触发刷新；仍无效时再重连代理，而不是连续切换多个出口。