Midjourney 任务卡住、一直加载，先确认是不是真的官方故障
不少人遇到生成失败第一反应是重新提交，但如果此时确实是官方服务出了问题，反复重试只会把任务队列堆得更乱。正确的第一步是先查 status.midjourney.com，确认网站、机器人、Discord 这几个组件是否都是绿色，以及当前 Fast/Relax 队列等待时长。若状态页都正常，问题大概率在你这一侧。
先区分任务卡住与加载失败，处理方式完全不同
任务提交后已经开始处理但卡在某个百分比不动，与任务从未开始的队列错误是两回事。单个任务卡在 Waiting to start 或某个百分比，直接取消重新提交就好，不需要深入排查；但如果预览图一直空白、下载失败，就需要往浏览器、网络层面排查。
浏览器与网络层面的常见原因
第三方 cookie 与脚本拦截插件
预览一直转或下载失败，常见原因包括浏览器限制了第三方 cookie、广告拦截类插件限制了资源域名。先确认浏览器的第三方 cookie 设置是否允许，或给 Midjourney/Discord 加个例外，再尝试无痕窗口/换个浏览器排除。
网络不稳定会直接导致“等待开始”类错误
不稳定的网络连接是很多“Waiting to start”错误的最常见诱因，优先尝试换成有线网络，比 WiFi 更稳定。需要提醒的是，质量不好的代理节点确实会拖慢请求，想靠接入方式改善体验，要选真正稳定低延迟的专线，而不是任意公共节点。
稳定链路能帮上什么忙
除了拖慢请求，质量差的公共节点还可能因为多人共用、高峰拥塞，导致预览图加载中途断开、下载需要多次重试。真正稳定的专线接入和“任意一个代理节点”完全不是同一回事，固定且专属的出口路径能显著降低这类中途断开的概率。通宝 VPN 的 AI 智能路由会针对 Midjourney、Discord 这类服务自动择优直连，搭配 IEPL 国际专线，让预览图/下载这类需要稳定传输的场景不容易因链路问题中途断开。
怎样判断问题出在本机、网络还是服务端
单靠“转圈不动”很难判断原因，可以用三个对照动作缩小范围，每个动作只需要几分钟。
- 打开浏览器开发者工具的 Network（网络）面板，重新触发一次加载，观察失败请求。请求长时间停在 pending、最后超时，多半是链路问题；很快返回 4xx 或 5xx 状态码，则更像权限或服务端问题。
- 用同一个账号换一台设备，或者把手机切到蜂窝网络再试一次。换环境后恢复，说明问题在原来的网络或浏览器；换了依然失败，就回到官方状态页和队列这一侧。
- 网站端和 Discord 端各提交一次同样的提示词。只有一个入口异常时，优先怀疑该入口自身的组件故障，而不是整条网络出了问题。
排查时顺手记下失败的具体时间和现象，例如卡在哪个百分比、是否出现错误码。需要联系客服或在社区求助时带上这些信息，对方更容易判断是不是已知故障。
排查时容易走的弯路
一是任务刚卡住就连续提交多个相同任务，这会占用并行额度，还可能让真正的结果淹没在一堆重复任务里；二是在不同接入线路之间频繁来回切换，每次切换都会让连接重新建立，反而更难判断到底是哪一条出了问题；三是一上来就重装浏览器、清空所有缓存，耗时长，却往往解决不了链路层面的原因。比较稳妥的做法是每次只改变一个变量，改完看一次结果，再决定下一步。
自查清单与总结
Midjourney 生成失败/加载慢，按下面顺序排查：
- 先查 status.midjourney.com，排除官方故障
- 区分任务卡住（取消重提）与预览/下载失败（查浏览器/网络）
- 确认第三方 cookie 设置没有拦截 Midjourney/Discord
- 换有线网络测试，排除家庭 WiFi 不稳定
- 如果用了代理/专线，确认是稳定专线而不是质量不确定的公共节点
常见问题
任务卡在 99% 怎么办？
这通常是服务端后处理环节卡住，在队列面板里删除卡住的任务并重新提交即可，不需要排查本地网络。
为什么有时用代理反而更慢？
质量不稳定的代理节点会额外叠加往返延迟甚至丢包，这不代表所有接入方式都会拖慢，稳定专线和质量不确定的公共代理是两回事。
多次刷新重试能加快恢复吗？
如果确认是服务端故障，频繁重试只会增加服务器负载，等待恢复后重新提交才是正确做法。
