Midjourney 用什么 VPN，不能只看网页能否打开。它的大部分日常操作发生在 Discord：客户端要维持网关长连接、发送交互指令、接收任务状态，再从媒体节点加载预览图和原图。线路即使能够打开 Discord 首页，只要长连接频繁重建、图片域名没有进入代理，实际体验仍会表现为指令一直等待、生成结果迟迟不出现，或者缩略图能看而原图下载失败。
因此，判断一条线路是否适合 Midjourney，需要把“登录成功”“指令响应”“图片回传”“持续连接”分开测试。线路类型方面，稳定的 IEPL 专线通常更适合长时间创作；质量可靠的中转线路适合兼顾成本与日常使用；直连线路则更依赖本地运营商、国际出口和使用时段。协议名称本身不是结论，客户端的分流、DNS 和传输配置同样会改变结果。
选择结论：长连接稳定优先于峰值速度
对 Midjourney 而言，优先级应当是连接连续性、丢包恢复、出口地区一致性，最后才是单次下载的峰值速度。生成指令本身数据量不大，但它依赖持续在线的 Discord 会话。线路发生短暂抖动时，网页测速可能仍然很好看，Discord 网关却可能断开并重新建立会话，导致交互状态延迟更新。
图片回传是另一条链路。预览图、放大图和下载文件可能由不同媒体主机提供。如果规则只代理 Discord 主站，而遗漏媒体域名，就会出现文字频道正常、图片区域持续空白的情况。选择 VPN 或代理服务时，需要确认客户端能够按域名分流，或者提供覆盖相关应用流量的 TUN 模式，而不是只提供浏览器扩展。
简要结论：长时间使用 Midjourney，优先选择稳定的 IEPL 专线或质量可靠的中转线路，并让 Discord 网关、交互请求和媒体域名使用同一出口。偶尔使用时可以先测试直连线路，但不应仅凭首页打开速度作判断。
- ✅ Discord 登录后能够持续保持在线，不反复显示重新连接。
- ✅ 发送绘图指令后，等待状态和生成结果能够连续更新。
- ✅ 频道内预览图、放大图与原图下载都能正常加载。
- ✅ 切换频道或暂时离开窗口后，返回时不会长时间补收消息。
- ✅ DNS 查询与实际连接使用一致的分流逻辑。
Discord 链路为什么比普通网页更挑线路
网关长连接负责事件推送
Discord 客户端登录后，会通过安全的 WebSocket 连接到网关。频道消息、机器人响应、交互状态等事件依靠这条连接持续推送。普通网页请求失败后，刷新即可重新获取内容；长连接则需要维持会话状态，发生中断后还要重连和恢复。线路抖动、连接跟踪超时或代理进程休眠，都可能让客户端表面仍然打开，实际事件却暂时停止更新。
这也是“延迟低”不等于“适合 Discord”的原因。某条线路在短请求中响应很快，但如果连接连续性较差，使用者仍会频繁看到消息延后集中出现。相反，峰值带宽不突出的稳定线路，往往能更顺畅地完成 Midjourney 的连续交互。
交互请求与媒体下载并非同一流量
发送指令、点击变化或放大操作时，客户端会产生交互请求；生成完成后，图片再从 Discord 的内容分发节点加载。两部分可能匹配不同的域名规则。如果客户端仅将主域名加入代理，交互可能成功，但图片请求仍然走本地网络。反过来，媒体可加载也不能证明网关长连接稳定。
浏览器版与桌面版还可能采用不同的网络入口。浏览器通常遵循浏览器或系统代理，桌面客户端则受操作系统代理、应用实现和客户端接管方式共同影响。遇到“浏览器能用、桌面端不行”时，不应立刻更换账号，而应先确认桌面应用的连接是否真正进入代理。
出口地区应保持连贯
创作过程中频繁切换国家或地区，会让 Discord 会话不断重建，也可能触发新的登录确认。更稳妥的做法是选定一个可持续使用的出口，在完成当次工作前保持不变。出口地区距离并非越远越好，应综合本地到入口的质量、入口到出口的传输路径，以及出口到 Discord 基础设施的连接情况。
测试重点不是“能不能打开”，而是同一出口能否完整承载登录、长连接、交互和媒体回传。只有四个环节都稳定，才算适合 Midjourney 的实际工作流。
线路类型对比：IEPL、中转与直连
线路名称描述的是传输路径，不直接等同于最终质量。IEPL 专线通常减少公网国际段的不确定性，适合持续在线和批量查看图片；中转线路先接入较近的入口，再由服务商转送到目标出口，实际表现取决于入口质量与中转调度；直连线路由本地网络直接访问境外节点，路径简单，但更容易受到本地国际出口变化影响。
| 线路类型 | 连接特征 | 适合场景 | 需要留意 |
|---|---|---|---|
| IEPL 专线 | 国际段路径相对可控，长连接通常更连贯 | 持续创作、频繁交互、连续查看原图 | 仍需确认入口质量与媒体域名分流 |
| 中转线路 | 先连接近端入口，再转送到境外出口 | 日常使用、兼顾稳定性与线路选择 | 入口拥塞或中转切换会影响长连接 |
| 直连线路 | 链路结构直接，表现依赖本地国际出口 | 轻度使用、本地网络路径较好时 | 不同时段的连接连续性可能变化 |
选择时不要把“专线”标签当作免测证明。即使线路类型合适，如果本地到入口存在无线网络干扰、客户端配置错误或 DNS 没有跟随代理，Discord 仍可能异常。反过来，在本地网络条件良好、距离出口合理的情况下，优质直连也可能满足短时使用。
较实用的办法是固定客户端、固定出口和固定测试流程，只替换线路类型。这样可以减少账号状态、浏览器缓存、设备休眠等变量。测试期间还应观察 Discord 是否出现重新连接提示，以及生成完成后图片是否一次加载完整，而不是只记录下载速度。
协议选择：名称不是稳定性的唯一答案
Shadowsocks、VMess、Trojan、VLESS、Hysteria2 与 TUIC 都可以承载跨境访问流量，但它们的传输方式、客户端支持和网络适应性不同。Midjourney 并不要求某个专用协议；真正重要的是协议在当前本地网络上能否稳定运行，以及客户端能否正确接管 Discord 的全部相关请求。
Shadowsocks、VMess、Trojan 与 VLESS
Shadowsocks 实现较成熟，客户端覆盖广，适合常规代理与域名分流。VMess 常见于相关代理生态，通常与传输层配置组合使用。Trojan 以 TLS 连接为基础，能否稳定取决于服务端、证书配置和链路质量。VLESS 本身不负责内容加密，实际部署通常依赖 TLS 等安全传输层，因此不能脱离完整配置单看协议名称。
这些协议常以 TCP 作为底层承载，对 Discord 的 WebSocket 长连接通常较直观。在线路丢包明显时，TCP 会重传并降低发送节奏，表现可能是消息和图片变慢，但会话未必立刻中断。若服务端拥塞或连接被频繁重置，换协议名称往往不能解决根本问题，仍应更换入口或线路。
Hysteria2 与 TUIC
Hysteria2 和 TUIC 基于 QUIC 与 UDP 传输，在存在一定丢包或路径波动的网络中可能获得更灵活的恢复表现。它们可以在代理隧道内承载应用的 TCP 请求，但这不意味着 Discord 的 WebSocket 本身变成了 UDP。应用层语义没有改变，变化的是代理隧道的底层传输方式。
这类协议是否合适，取决于当前网络对 UDP 的支持。如果公司网络、公共网络或路由设备限制 UDP，连接可能无法建立，或者稳定性反而不如基于 TCP 的方案。遇到此类情况，应保留一个 TCP 传输节点作为回退，而不是反复修改 Discord 设置。
| 协议类别 | 主要特征 | 对 Discord 的意义 | 常见限制 |
|---|---|---|---|
| Shadowsocks | 实现成熟，分流客户端较多 | 适合常规长连接与媒体访问 | 最终表现主要取决于线路与服务端负载 |
| VMess / Trojan / VLESS | 可组合不同安全层与传输方式 | 便于按网络环境选择传输配置 | 配置项较多，错误组合会造成连接失败 |
| Hysteria2 / TUIC | 基于 QUIC 与 UDP，恢复策略灵活 | 在适合的网络中可改善波动体验 | 受 UDP 可用性和本地网络策略影响 |
协议结论：家庭网络可先使用客户端支持成熟的 TCP 类配置；确认 UDP 路径可用后，再比较 Hysteria2 或 TUIC。无论采用哪种协议，都应以 Discord 长连接和图片完整加载作为判断标准，而不是依据协议名称排序。
客户端分流：把网关、交互与图片一起纳入
订阅链接通常包含节点名称、服务器地址、端口、协议和认证信息。导入客户端后，仍需要选择代理模式。全局模式最容易排除漏代理问题，但会让其他应用也经过同一出口；规则模式更适合长期使用，不过需要确保 Discord 与 Midjourney 相关域名被完整匹配；TUN 模式则在系统网络层接管流量，更适合桌面客户端不完全遵循系统代理的情况。
订阅链接应当像密码一样保管。链接中的认证信息可能允许他人使用对应服务，不应贴到公开论坛、截图或问题工单的可见区域。需要排查时，可以提供已遮蔽服务器地址和认证字段的配置摘要，而不是发送完整订阅。
规则应覆盖哪些请求
规则至少要覆盖 Discord 主站、网关、内容分发与媒体主机，以及 Midjourney 网站自身。域名结构可能调整，因此优先使用客户端维护的规则集，并定期更新订阅和规则。手工规则适合用于验证，不宜把某个临时主机名视为永久清单。
规则思路：
Discord 主站与网关 → 指定代理
Discord 内容分发与媒体主机 → 同一代理
Midjourney 网站与资源请求 → 同一代理
本地网络与常用国内服务 → 直连
未匹配流量 → 按实际需求选择让网关和媒体流量使用同一出口，可以减少会话路径不一致带来的排查难度。如果不同规则组自动选择不同节点，文字事件可能从一个地区进入，图片请求却从另一个地区发出。虽然这种配置不一定立即失败，但会让登录状态、缓存命中和连接稳定性变得难以判断。
各平台的接管方式不同
Windows 与 macOS 桌面端可优先检查系统代理和 TUN 模式。Discord 桌面应用基于 Electron，但不同版本和系统环境对代理设置的继承并不完全相同；系统代理可用而桌面端异常时，TUN 往往更适合作为排查手段。使用 TUN 后还要确认本地局域网访问需求，避免把打印机、存储设备等本地地址错误送入代理。
iPhone 与 iPad 上的代理客户端通常通过系统 VPN 接口接管流量，规则由客户端内部执行。切换网络、设备休眠或低电量策略可能使隧道重新建立，返回 Discord 后应等待连接恢复再发送指令。Android 的客户端实现差异较大，需要确认 Discord 没有被加入绕过列表，同时检查系统是否限制代理客户端在后台运行。
浏览器版最适合做交叉验证。若浏览器版和桌面端在同一节点下表现不同，通常说明应用接管范围不同，而不是线路本身完全不可用。此时应比较系统代理、TUN 和浏览器代理的路径，而不是不断切换出口地区。
DNS 泄漏与“连接成功但图片不显示”
DNS 决定域名被解析到哪个地址。如果连接通过代理，而 DNS 查询仍由本地网络处理，就可能得到不适合当前出口的解析结果，或者让部分域名解析失败。更常见的影响不是隐私提示，而是分流失配：客户端需要先知道域名，才能把请求送入正确规则；解析过程被系统提前处理后，规则可能只看到目标地址，无法按域名匹配。
解决思路是让 DNS 与代理模式保持一致。规则模式应使用客户端支持的远程解析或加密 DNS，并确认解析请求自身遵循预期路径；TUN 模式应检查 DNS 劫持或虚拟解析功能是否启用；浏览器如果启用了独立的安全 DNS，也应确认它不会绕过客户端规则。
图片不显示还可能来自媒体域名漏代理、缓存中的失败响应、桌面端没有进入代理，或者服务端图片仍在处理。可以先在同一设备的浏览器中打开图片地址：浏览器能打开而客户端不能，重点检查应用接管；两边都不能打开，重点检查媒体规则、DNS 与线路；普通网站也异常，则先处理本地网络或代理连接。
可复现实测：按同一流程比较线路
所谓实测，不应只截取一次测速结果。更可靠的方法是固定设备、客户端、DNS 和出口地区，在相近的网络环境下依次比较线路。测试内容要覆盖会话建立、交互、图片加载和恢复能力，并记录可观察的现象，而不是凭“感觉更快”下结论。
- 确认本地基线。暂时停止大文件同步、系统更新和其他高流量任务，确认当前 Wi-Fi 或有线网络本身没有频繁断开。
- 固定客户端配置。选择同一种代理模式与 DNS 设置，导入最新订阅，避免测试过程中自动切换节点。
- 检查出口一致性。连接后通过网络检测页确认出口已变化，再启动 Discord，不要在测试中途切换地区。
- 观察网关连接。打开多个已有频道，查看消息是否连续出现，并留意客户端是否反复显示连接恢复。
- 执行完整交互。发送正常的 Midjourney 指令，观察等待状态、生成完成提示、变化与放大操作是否依次返回。
- 检查媒体回传。分别打开预览图和原图，确认没有缩略图可见而下载链接失败的情况。
- 模拟恢复。短暂切换应用或让设备进入休眠，再返回 Discord，检查会话与图片请求能否恢复。
- 只替换线路。保持其他设置不变，依次测试 IEPL、中转或直连，记录重连、等待和媒体加载现象。
| 观察现象 | 优先怀疑 | 下一步 |
|---|---|---|
| 普通消息也延迟集中出现 | 网关长连接不稳定 | 更换线路入口，检查 TUN 与后台限制 |
| 指令有回应但图片空白 | 媒体域名漏代理或 DNS 失配 | 补全规则，并让媒体请求使用同一出口 |
| 浏览器正常，桌面端异常 | 桌面应用未进入代理 | 检查系统代理，使用 TUN 交叉验证 |
| 切换网络后一直等待 | 隧道或会话尚未恢复 | 重新连接代理，再重启 Discord |
| 所有客户端同时异常 | 本地网络、线路或服务状态 | 先查公开状态，再更换入口测试 |
常见故障的判断顺序
Discord 显示在线，但指令一直等待
先在其他频道收发普通消息。如果普通消息正常，检查 Midjourney 服务状态和当前频道权限；如果普通消息也有明显延后，则检查网关长连接。不要连续重复提交相同指令，这会混淆任务状态。可以关闭 Discord 后重新连接代理，再启动客户端，让新会话从固定出口建立。
预览图可见，原图打不开
这通常说明基础消息和部分媒体请求已经成功，但原图地址对应的主机没有进入同一规则，或者缓存保留了先前的失败结果。复制图片链接到同一设备的浏览器测试，并确认浏览器也使用相同代理。若浏览器正常，应回到桌面端接管方式；若浏览器也失败，则检查媒体域名与 DNS。
线路切换后要求重新确认登录
频繁跨地区切换出口会改变会话环境。完成登录后应固定一个地区，不要让客户端的自动选择策略在多个国家之间跳转。自动测速可以用于初选，但创作期间更适合锁定已验证的节点。若必须切换，先保存当前工作，再完整重启 Discord 会话。
语音正常，文字或图片异常
Discord 的语音、网关和媒体流量并非完全相同。某一功能正常不能证明全部规则正确。应分别检查应用的 TCP 与 UDP 接管、域名分流和 DNS。只使用浏览器扩展时，桌面客户端与语音流量通常不会自动进入扩展代理，此时应改用系统级客户端。
最终建议：按使用强度选择，不追逐节点标签
如果 Midjourney 是持续使用的创作工具，应优先考虑 IEPL 专线或经过完整流程验证的中转线路，并固定出口地区。客户端采用规则模式时，要同时覆盖 Discord 网关、交互与媒体请求；桌面应用不遵循系统代理时，再使用 TUN。协议可先从支持成熟、回退方便的配置开始，根据本地网络是否稳定支持 UDP，再比较 Hysteria2 或 TUIC。
如果只是偶尔生成图片，直连线路也可以测试，但判断标准仍然是完整工作流，而不是主页打开速度。任何线路都可能受本地网络、入口和使用环境影响，因此应保留已验证的备用节点，并保存一套稳定的客户端配置。遇到异常时，先区分服务状态、网关连接、媒体分流和 DNS，通常比无目的地反复切换节点更有效。
归根结底，Midjourney 的网络选择是一项链路匹配问题：入口要适合当前本地网络，传输要能维持 Discord 长连接，出口要保持连贯，规则还要覆盖图片回传。把这些环节分别验证后，IEPL、中转和直连的差异才有实际意义。