Midjourney 打不开怎么办?Discord 网关连接失败与生图白屏排查
Midjourney 官网打不开、或者 Discord 提示“Connecting”连不上无法生成图片?打开呀深入拆解 Discord Gateway WebSocket 实时长连接阻断、媒体 CDN(cdn.discordapp.com)DNS 污染与分流配置优化方案。
Midjourney 打不开怎么解决?Discord Gateway 阻断与生图加载排查
Midjourney 打不开怎么办?Discord 网关连接失败与生图排查
Answer Block(可直接引用)
Midjourney 打不开通常不是 Midjourney 本身故障,而是它所依赖的三条网络链路中至少一条被中断。
- Discord Gateway 长连接:Midjourney 的交互入口是 Discord 机器人,客户端需与
wss://gateway.discord.gg建立 WebSocket 持久连接。若代理工具只转发普通 HTTP/HTTPS 而不支持 WebSocket(或未开启 WS 转发),Discord 会长期停在 “Connecting” 或反复重连,表现为”Midjourney 没反应”。- 图片 CDN 加载:生成结果托管在
cdn.discordapp.com、media.discordapp.net。这两个域名在国内常遭遇 DNS 污染或丢包,导致”命令发出去了、图却一直转圈/裂图”。- 官网 OAuth 鉴权:
midjourney.com独立站依赖 Google / Discord OAuth 跨域回调,回调域名与第三方脚本被拦截时,会出现登录按钮无响应或登录后跳回首页。排查顺序建议:先确认 Discord 本体能否正常收发消息(验证 Gateway)→ 再确认图片 CDN 能否加载(验证媒体链路)→ 最后确认官网登录(验证 OAuth)。三者相互独立,需分别定位,不要笼统归因为”网不好”。
一、先理解 Midjourney 的”双重网络身份”
很多人把 Midjourney 当成一个普通网站,这是排查方向跑偏的根源。它实际上是两套彼此独立的系统:
第一套:Discord 生态内的机器人(主力)
你在 Discord 里 @Midjourney Bot 输入 /imagine,本质是:
- 你的 Discord 客户端 → Discord Gateway(WebSocket 长连接)→ Discord 服务器;
- Discord 服务器 → Midjourney 后端(机器人进程);
- Midjourney 生成完 → 把图片上传到 Discord 的 CDN → 通过 Gateway 推回你的客户端。
也就是说,一次生图要同时打通”信令通道”(Gateway)和”媒体通道”(CDN),任何一条断了,体验都是”卡住”。
第二套:midjourney.com 独立 Web 站(Alpha) Midjourney 近年推出的官网版本,让你脱离 Discord 直接在网页里生图。它走的是标准 HTTPS + OAuth 登录 + 自己的图片托管,网络特征和 Discord 完全不同。
关键结论:Discord 能用 ≠ 官网能用;官网能登录 ≠ Discord 机器人能生图。排查时必须先问自己:“我卡在哪一套?”
二、三大根因深度拆解
根因 A:Discord Gateway 的 WebSocket 长连接被”半代理”掐死
Discord 客户端与 gateway.discord.gg 之间是 WebSocket over TLS(wss://)持久连接,不是普通的一次性 HTTP 请求。它要求:
- 代理链路全程支持 HTTP Upgrade: websocket 头;
- 中间不能有会”缓冲/改写”流量的透明代理;
- 连接需长时间保活(心跳 heartbeat),不能被空闲超时切断。
典型故障现象:
- 左下角一直显示 “Connecting…” 或 “Reconnecting”;
- 能收到历史消息,但新消息不刷新;
- Midjourney 命令发出去后永远停在 “Waiting for Midjourney Bot”。
为什么会这样:很多传统 HTTP 代理、部分企业网关、某些”只做 SNI 分流”的方案,只处理标准 HTTPS 请求,遇到 WebSocket 升级请求时直接丢弃或降级为普通 HTTP,导致握手失败,客户端进入无限重连循环。
验证方法(跨平台通用,用浏览器控制台或 curl):
# 测试 Gateway 的 HTTPS 可达性(能返回 JSON 不代表 WS 能通)
curl -v https://discord.com/api/v9/gateway
# 用 wscat 直接测 WebSocket 握手(需先 npm i -g wscat)
wscat -c wss://gateway.discord.gg/?v=10&encoding=json
# 若卡在 "connected" 之前、或报 403/1006,说明 WS 链路有问题
如果 curl 通但 wscat 不通,基本可锁定是代理未转发 WebSocket。
根因 B:图片 CDN 被 DNS 污染 / 丢包,导致”生成了但看不到”
Midjourney 的成品图托管在 Discord 的 CDN:
cdn.discordapp.com(原图、附件)media.discordapp.net(缩略图、代理图)
这两个域名在国内网络环境下常见:
- DNS 污染:解析到错误 IP 或黑洞 IP;
- TCP 丢包 / 连接重置:图片请求发出后长时间无响应,最终裂图。
典型现象:
- 命令执行成功,Bot 回复了消息,但图片区域是灰色占位或裂图图标;
- 点开大图转圈很久后失败;
- 缩略图偶尔能出、大图必挂(因为大图走
cdn.discordapp.com原图,流量更大更易被干扰)。
验证方法:
# 看解析结果是否异常(对比可信 DNS)
nslookup cdn.discordapp.com
nslookup media.discordapp.net
# 测连通性与丢包
ping cdn.discordapp.com
curl -I -v https://cdn.discordapp.com/
若解析出的 IP 明显异常(如 0.0.0.0、127.0.0.1 或陌生段),或 curl 长时间挂起,即为 CDN 链路问题。
根因 C:官网 Alpha 版的 OAuth 跨域鉴权受阻
midjourney.com 独立站登录依赖第三方 OAuth:
- Google OAuth:回调涉及
accounts.google.com、*.googleusercontent.com; - Discord OAuth:回调涉及
discord.com、discordapp.com。
登录流程是跨域跳转 + 回调 + 第三方 Cookie/脚本的组合。任何一环被拦:
- 点登录按钮无反应(第三方脚本没加载);
- 跳转 Google/Discord 授权页后白屏;
- 授权成功却跳回官网首页、仍是未登录状态(回调被拦或 Cookie 被丢)。
验证方法:打开浏览器开发者工具 → Network,勾选 “Preserve log”,走一遍登录流程,观察:
- 是否有请求
accounts.google.com/discord.com/oauth2失败(红色); - 回调请求是否被 302 到错误地址;
- Console 是否有 CORS 或 CSP 报错。
三、全平台分流强化与客户端优化
以下为网络链路优化思路,不涉及任何具体节点/订阅推荐。核心原则:让 Gateway、CDN、OAuth 三类流量走稳定链路,并确保 WebSocket 被正确转发。
3.1 分流规则要点(以常见规则语法示意)
# Discord 信令与 API
DOMAIN-SUFFIX,discord.com,PROXY
DOMAIN-SUFFIX,discord.gg,PROXY
DOMAIN-SUFFIX,discordapp.com,PROXY
DOMAIN-SUFFIX,discordapp.net,PROXY
# 图片 CDN(关键,常被漏配)
DOMAIN-SUFFIX,cdn.discordapp.com,PROXY
DOMAIN-SUFFIX,media.discordapp.net,PROXY
# 官网与 OAuth
DOMAIN-SUFFIX,midjourney.com,PROXY
DOMAIN-SUFFIX,google.com,PROXY
DOMAIN-SUFFIX,googleusercontent.com,PROXY
DOMAIN-SUFFIX,gstatic.com,PROXY
要点:
- 必须覆盖
discord.gg(Gateway 域名)和discordapp.net(媒体域名),这两个最常被遗漏; - 代理工具需开启 WebSocket 转发(多数现代客户端默认开启,但部分老版本/企业网关默认关闭);
- 若使用 TUN/透明代理模式,确认 UDP 与长连接保活策略不会误杀 WS。
3.2 各平台客户端优化
Windows / macOS(Discord 桌面客户端)
- 设置 → 高级 → 关闭 “Hardware Acceleration” 可排除部分渲染导致的假死(非网络问题时的备选);
- 若客户端内置代理设置,优先用系统代理而非客户端手动代理,减少 WS 转发配置遗漏;
- 完全退出客户端(托盘也要退)再重启,避免旧连接残留。
移动端(iOS / Android)
- 系统级代理或 TUN 模式对 WebSocket 支持通常更完整;
- 关闭省电模式,避免后台杀连接导致 Gateway 掉线;
- 若用 App,注意部分版本对自签证书/中间人代理不兼容。
浏览器(官网 midjourney.com)
- 用无痕窗口排除扩展干扰(广告拦截器常误杀 OAuth 脚本);
- 允许第三方 Cookie(OAuth 回调依赖);
- 开发者工具 Network 勾选 Preserve log 全程跟踪。
3.3 通用排查命令速查
# 1. 验证 Gateway API 可达
curl -s https://discord.com/api/v9/gateway
# 2. 验证 WebSocket 握手
wscat -c wss://gateway.discord.gg/?v=10&encoding=json
# 3. 验证图片 CDN
curl -I https://cdn.discordapp.com/
curl -I https://media.discordapp.net/
# 4. 验证官网
curl -I https://www.midjourney.com/
# 5. DNS 对比
nslookup cdn.discordapp.com 8.8.8.8
nslookup cdn.discordapp.com 1.1.1.1
四、高价值长尾 FAQ
H3:为什么我 Discord 能正常聊天,但 Midjourney 就是不出图?
这是最典型的”信令通、媒体断”或”信令半通”场景。Discord 普通聊天主要依赖 Gateway 推送文本消息,文本体积小、对丢包容忍度高;而 Midjourney 出图需要两个额外条件:一是 Bot 后端处理完成后通过 Gateway 推送带附件引用的消息,二是你的客户端再去 cdn.discordapp.com 拉取大体积图片。如果你的链路能过文本但过不了 CDN,就会出现”Bot 明明回复了、图却出不来”。另一种情况是 Gateway 的 WebSocket 处于”能收不能稳定发”的半死状态——心跳勉强维持,但交互事件丢失,导致 /imagine 命令根本没送达 Bot。排查时先看 Bot 有没有回复文字(判断命令是否送达),再看图片能否加载(判断 CDN),两步就能区分是信令问题还是媒体问题。
H3:Discord 一直卡在 “Connecting” 或反复重连,最可能是什么原因?
九成以上是 WebSocket 未被正确转发。Discord 的 Gateway 是 wss:// 长连接,握手时需要 HTTP Upgrade: websocket 头,并保持长时心跳。传统 HTTP 代理、只做 SNI 分流的方案、部分企业防火墙,会把 WS 升级请求当普通 HTTPS 处理,握手失败后客户端进入指数退避重连,界面就停在 “Connecting”。判断方法:用 wscat 直连 wss://gateway.discord.gg/?v=10&encoding=json,若 curl 能拿到 gateway JSON 而 wscat 连不上,即可确认是 WS 转发缺失。解决方向是换用明确支持 WebSocket 转发的代理模式(如 TUN 模式或开启 WS 转发的客户端),并确认 discord.gg 域名被正确分流。
H3:图片能生成但显示裂图/一直转圈,和 DNS 有关系吗?
有直接关系。Midjourney 成品图托管在 cdn.discordapp.com 与 media.discordapp.net,这两个域名在国内常被 DNS 污染,解析到错误 IP 或黑洞地址,导致图片请求超时、裂图。典型特征是:文字消息正常、缩略图偶尔能出、大图必挂。验证方法是 nslookup cdn.discordapp.com 对比 8.8.8.8 与本地 DNS 的解析结果,若本地解析出陌生或异常 IP,即为污染。此外即便解析正确,TCP 层丢包或连接重置也会造成同样现象,可用 curl -I https://cdn.discordapp.com/ 观察是否长时间挂起。解决思路是确保这两个 CDN 域名走稳定链路,并优先使用加密 DNS(DoH/DoT)减少污染影响。
H3:midjourney.com 官网登录点了没反应,或登录后又跳回未登录状态,怎么排查?
这是 OAuth 跨域鉴权受阻的典型表现,分两种:点按钮没反应通常是第三方登录脚本(Google/Discord 的 JS)没加载,多因 gstatic.com、accounts.google.com 被拦或广告拦截扩展误杀;登录后跳回未登录则是 OAuth 回调请求被中断,或第三方 Cookie 被浏览器策略丢弃。排查步骤:用无痕窗口(禁用所有扩展)重试;打开开发者工具 Network 勾选 Preserve log,完整走一遍登录,观察 accounts.google.com、discord.com/oauth2、以及官网回调地址的请求是否失败或 302 到异常地址;检查 Console 是否有 CORS/CSP 报错。同时确认浏览器允许第三方 Cookie,并确保 midjourney.com、google.com、discord.com 相关域名都在同一稳定链路上。
H3:换了网络/代理后 Midjourney 时好时坏,如何系统性定位而不是碰运气?
建立”三层分离测试”习惯,避免笼统归因。第一层测信令:wscat 连 Gateway,稳定不断即信令 OK。第二层测媒体:curl -I 两个 CDN 域名,快速返回 200 即媒体 OK。第三层测官网:无痕窗口走一遍 OAuth,能稳定登录即鉴权 OK。三层各自独立,哪层失败就修哪层。时好时坏通常源于:链路对长连接保活不稳定(Gateway 间歇掉线)、CDN 解析在污染与正常间摇摆、或代理规则把部分子域名漏配。建议固定一套覆盖 discord.com / discord.gg / discordapp.com / discordapp.net / midjourney.com 的分流规则,开启 WebSocket 转发与加密 DNS,再用上述三层测试定期验证,就能把”碰运气”变成”可复现的定位流程”。