选择 Midjourney 加速器时，不能只看网页能不能打开。Discord 桌面端或网页端还要持续维护 WebSocket 长连接，发送交互指令、接收任务状态，并从图片分发节点加载结果。普通网页偶尔抖动可能只是多等一会儿，而 Discord 长连接反复断开，会表现为指令停住、按钮点击无反馈、频道内容延迟刷新，甚至图片一直停在加载状态。
因此，适合浏览国际网站的线路，不一定适合 Midjourney。真正需要核对的是连接稳定性、出口一致性、路由质量和客户端接管范围。下面先拆解完整通信过程，再比较直连、中转与 IEPL，最后给出可执行的协议选择、分流和故障排查方法。
为什么 Midjourney 能打开，Discord 仍可能卡住
Midjourney 的 Discord 工作流并不是一次普通网页请求。用户在频道里提交提示词后，客户端要把交互发给 Discord，持续接收频道与任务状态，再从相关域名和内容分发节点读取图片。任何一段没有被正确代理，都可能让流程停在中间。
最常见的误判是“首页能开，所以线路没问题”。网页首页主要依赖短连接，请求失败后浏览器通常会自动重试；WebSocket 则是一条持续存在的双向连接。线路切换、出口地址变化、系统休眠、代理进程被省电策略暂停，都会让现有会话断开。客户端虽然可能尝试重连，但重连期间发出的交互不一定能及时显示结果。
另一类问题来自分流遗漏。浏览器可能已经走代理，但 Discord 桌面端仍按系统默认路由连接；也可能主站域名已加入规则，图片域名却继续直连。此时文字频道看起来正常，生成结果的缩略图却打不开。反过来，如果只代理图片节点而 Gateway 没有进入代理，频道刷新和按钮交互仍会不稳定。
判断线路是否适合 Midjourney，应完成一次连续流程：进入 Discord、提交交互、观察任务状态更新、打开生成结果并下载图片。只测试网站首页，无法覆盖长连接和 CDN 路径。
挑选 Discord 线路要核对的四个硬指标
连接抖动比单次延迟更重要
延迟表示数据往返所需时间，但单次显示较低，不代表持续连接稳定。对于 Discord，更值得关注的是延迟是否频繁跳动、是否出现连续丢包，以及连接保持一段时间后会不会重置。线路即使平均延迟不算最低，只要波动较小，交互体验往往比“偶尔很快、偶尔断线”的线路更可靠。
出口地区需要保持一致
登录期间不要频繁在相距很远的出口地区之间切换。出口改变会让原有 TCP、TLS 和 WebSocket 会话全部失效，Discord 客户端必须重新建立连接。选择与当前网络路由相对匹配、并且可以持续使用的出口，比在多个地区之间来回追逐最低延迟更实用。
线路需要完整承载长连接
部分代理配置只覆盖浏览器，或者仅代理规则列表中的常见网页域名。要确认 Discord Gateway、登录接口、媒体资源以及 Midjourney 相关请求都进入同一套可用路径。使用规则模式时，还要留意域名变化和规则库更新；规则不全时，可暂时使用全局或 TUN 模式做对照测试。
晚间拥塞与持续传输能力
生成图片本身通常不是超大文件传输，但频道刷新、预览加载和下载会连续使用线路。拥塞线路可能在短测速中表现正常，实际使用一段时间后却出现排队和重传。测试时不要只刷新一次页面，应连续执行完整工作流，并观察同一出口在常用时段的表现。
- ✅ Discord 连接后可以持续刷新频道，状态不会频繁变成重连。
- ✅ 提交提示词后，任务状态与按钮交互能够连续更新。
- ✅ 预览图、放大结果和下载请求都能通过同一套分流规则。
- ✅ 固定出口使用时，延迟波动和丢包表现保持平稳。
- ❌ 只凭测速页面的峰值带宽判断线路是否适合长连接。
- ❌ 每次卡顿就立即更换到相距很远的出口，导致会话重复重建。
直连、中转与 IEPL 专线有什么区别
这里的“直连”是指用户网络直接连接境外代理入口；“中转”是在境内或邻近地区增加入口节点，再由中转链路送往境外出口；IEPL 通常指利用国际以太网专线承载其中一段跨境传输，再从境外网关进入目标网络。三者描述的是传输路径，不等同于具体加密协议。
| 线路类型 | 路径特征 | 对 Discord 的影响 | 适合情形 |
|---|---|---|---|
| 直连 | 本地网络直接连接境外入口，路径受当前运营商国际路由影响较大 | 路由良好时结构简单；拥塞或绕路时，WebSocket 更容易抖动 | 本地到目标地区路由稳定，且希望减少中间环节 |
| 中转 | 先连接较近入口，再由服务侧选择后续链路与境外出口 | 可以避开部分不理想的直连路由，但体验取决于入口与中转段质量 | 直连经常绕路，或不同运营商之间表现差异明显 |
| IEPL | 跨境路径中的一段由专线承载，境外出口后仍需访问公共网络 | 通常更重视路径可控性与波动表现，但不能把“专线”直接理解为所有目标都不会拥塞 | 长时间使用 Discord，对持续连接稳定性要求更高 |
IEPL 的价值主要在跨境段，而不是让整条请求路径都脱离公共互联网。数据到达境外网关后，仍要经过出口网络访问 Discord 与 CDN。因此，判断一条 IEPL 是否合适，仍需实际检查出口地区、境外互联和客户端规则。只看到线路名称，不足以得出体验结论。
中转也不是层级越多越好。每增加一个转发环节，就多一个可能拥塞或失效的位置。好的中转会选择更合适的入口和后续路由；不合理的中转则可能增加延迟与故障面。测试时应固定协议、客户端和出口，只替换线路类型，否则无法判断改善究竟来自哪一项。
加速器协议怎么选：Shadowsocks、VMess、Trojan、VLESS、Hysteria2 与 TUIC
协议影响握手方式、传输承载、客户端兼容性和弱网表现，但协议名称本身不能代替线路质量。相同协议放在不同入口、不同路由和不同负载环境中，结果可能完全不同。选择时应先确认客户端支持，再结合当前网络是否限制 UDP、是否需要 TUN 接管，以及服务端提供的传输方式判断。
基于 TCP 的常见选择
Shadowsocks 结构相对直接，客户端覆盖广，适合需要简单代理与规则分流的环境。VMess 和 VLESS 常由 Xray、sing-box 等内核支持，可搭配不同传输层；VLESS 本身不负责额外加密，通常需要与 TLS 等安全层正确组合。Trojan 的连接建立依赖 TLS 配置，适合客户端和服务端都已正确提供证书与传输参数的场景。
对 Discord 而言，TCP 承载的方案通常具有较好的网络兼容性。如果所在网络对 UDP 不友好，先选择稳定的 TCP 路径更容易排除问题。不过，TCP 路径一旦发生持续丢包，重传与队头阻塞也会放大交互等待，因此仍要看实际线路而不是只看协议标签。
基于 QUIC 与 UDP 的选择
Hysteria2 和 TUIC 使用基于 UDP 的 QUIC 思路，在部分高延迟、容易丢包的网络中可以更灵活地处理并发流和重传。它们并不保证在所有网络里更快：企业网络、公共 Wi-Fi 或部分路由环境可能限制 UDP，表现会变成连接失败、握手缓慢或频繁回退。
测试方法很直接：保持出口地区不变，分别使用可用的 TCP 与 UDP 方案执行相同的 Discord 工作流。如果 UDP 协议频繁断开，而 TCP 可以稳定保持频道更新，就应优先考虑兼容性；如果两者都不稳定，则更可能是入口路由、出口拥塞、DNS 或分流问题。
不要同时更换协议、线路、出口和客户端。一次只改一个变量，并在相同网络环境下复测，否则短暂恢复也无法定位真正原因。
客户端导入与分流规则怎样设置
订阅链接通常包含节点列表与连接参数，导入客户端后还需要选择代理模式。导入成功只表示客户端读到了配置，不代表 Discord 的全部请求已经进入代理。桌面端最容易出问题，因为浏览器、Discord 应用和系统 DNS 可能走不同路径。
- 导入订阅。在客户端的订阅管理中粘贴服务提供的订阅链接，更新后确认节点名称与协议被正常解析。订阅链接应视作访问凭据，不要发布到公开页面或截图中。
- 先做全局对照。短暂使用全局或 TUN 模式测试 Discord 完整流程。如果全局模式正常而规则模式异常，问题通常在规则覆盖，而不是节点本身。
- 补全域名规则。除 Discord 主域名外，还要覆盖登录、Gateway、附件与图片分发相关域名，以及 Midjourney 网站和其实际调用的资源域名。域名可能调整，应以客户端连接日志和维护中的规则集为准。
- 统一 DNS 路径。启用客户端提供的远程解析、加密 DNS 或 TUN DNS 接管时，要确认域名解析结果与代理路径一致，避免请求已代理而 DNS 仍从本地网络发出。
- 固定出口复测。关闭自动切换，选择一个出口完成登录、交互、加载和下载。确认稳定后，再决定是否恢复自动选择。
Windows 与 macOS
Windows 客户端常见系统代理与 TUN 两种接管方式。系统代理主要影响遵循系统设置的应用，而部分桌面程序或后台连接可能不完全遵循；TUN 会在网络层接管更多流量，更适合判断是否存在漏代理。macOS 也有系统代理和网络扩展模式，首次启用网络扩展时需要在系统界面完成授权。如果浏览器正常而 Discord 应用异常，应优先对照 TUN 或网络扩展模式。
Android 与 iOS
移动端客户端一般通过系统 VPN 接口接管流量。Android 需要留意省电策略是否暂停代理客户端；系统回收后台进程后，Discord 的长连接会一起断开。iOS 切换网络、设备休眠或低电量状态也可能触发重连。移动端排查时，应保持客户端在运行状态，并观察状态栏中的连接标识是否持续存在。
DNS 泄漏与规则遗漏
DNS 泄漏是指域名查询没有按预期进入设定的解析路径，仍由本地网络处理。它不一定直接导致 Discord 断线，但可能造成域名解析失败、返回不合适的节点，或让分流规则无法按域名命中。可先在全局模式下使用本站网络检测核对出口与 DNS，再回到规则模式比较差异。
Discord 卡顿时的排查顺序
排查要从最容易验证的环节开始。不要看到图片加载失败就直接认定线路不可用，也不要因为网页打开正常就排除代理问题。下面的顺序可以逐步缩小范围。
- ✅ 先确认代理客户端仍处于连接状态，订阅没有导入错误或过期配置。
- ✅ 固定当前出口，重新连接后观察 Discord 是否完成 Gateway 重连。
- ✅ 用浏览器版与桌面版做对照，判断是否只有桌面应用未被系统代理接管。
- ✅ 临时切到全局或 TUN 模式，检查文字、交互与图片是否同时恢复。
- ✅ 查看客户端连接日志，确认 Discord、附件 CDN 和 Midjourney 请求命中了代理规则。
- ✅ 对照 TCP 与 UDP 协议，判断当前网络是否对 QUIC 类传输有限制。
- ❌ 在任务生成过程中连续切换节点，旧会话会被中断，排查结果也会失去参考价值。
如果浏览器版正常、桌面版异常，优先检查系统代理接管范围和应用分流；如果文字正常但图片异常，重点检查 CDN 域名与 DNS；如果所有内容都会周期性停住，重点检查 WebSocket 重连、线路抖动和系统省电；如果只有某个出口异常，则可能是该出口到目标服务的境外路由问题。
自动选择节点也可能造成干扰。部分客户端按一次探测结果挑选最低延迟节点，但最低延迟不等于长连接最稳定。自动切换还可能在后台把会话迁移到另一个出口。用于 Discord 时，可以先关闭自动切换，在确认稳定的节点上完成一段连续操作，再决定是否启用故障转移。
完成排查后，保留一套已验证的客户端模式、协议和固定出口作为基准配置。以后遇到异常，先回到基准配置复测，可以更快区分本地设置变化与线路变化。
Midjourney 线路选择结论
Midjourney 加速器的核心不是把某次测速做到最高，而是让 Discord Gateway、交互接口和图片分发请求稳定地走完同一条可控路径。选择时依次看长连接抖动、出口一致性、路由类型和客户端接管范围，再根据当前网络对 TCP 或 UDP 的兼容情况选择协议。
直连适合本地国际路由本身稳定的环境；中转可以改善部分绕路问题；IEPL 更侧重跨境段的路径可控性，但仍需检查境外出口与目标网络。客户端方面，先用全局或 TUN 模式确认线路，再通过日志补全 Discord、Midjourney 与 CDN 的分流规则，同时让 DNS 解析路径与代理策略保持一致。