生图和文件上传一起挂掉，卡住的不是对话，是那条文件通道。
官方在事件期间的说法是标准流程用语：已定位问题，正在采取缓解措施并评估效果，但部分图像请求仍可能失败。根因至今没有公开说明。
值得留意的是这次故障的形状：出问题的不只是图像生成，还有文件上传——一个是模型侧的生成任务，一个是纯粹的传输与存储动作。两者同时失效，通常不会是模型推理本身出事，更像是它们共用的那段基础设施出了问题：对象存储、上传网关，或者中间那层负责把二进制交给模型的服务。
这只是从症状反推的合理猜测，OpenAI 没有公布任何根因细节。但它能解释一个用户侧的困惑——为什么明明只是想传一张图，对话框也跟着卡住不动：卡住的不是对话，是那条文件通道。
时间线上有个巧合值得记一笔：故障公告的最后一次更新是「已修复」，紧接着的一句就是 Images 2.5 发布。新旧图像模型的切换涉及流量灰度、推理集群扩缩容和上传管线的改造，任何一环在切换窗口里抖一下，表现出来都会是生图报错加上传失败。
需要说清楚的是，官方并没有把这两件事关联起来，也没有说故障是发布导致的。目前能确认的只有时间相邻。但对于依赖这条链路干活的人来说，重大版本切换前后是故障高发期，这个经验规律不因官方是否承认而改变。
全局故障和个人问题在表现上高度相似，这才是最耗时间的地方。图像一直转圈、上传卡死、请求超时——服务端出事是这个样子，出口 IP 被判定异常、账号触发风控、代理链路半通不通，同样是这个样子。用户往往先花半小时折腾自己的网络，最后才发现是对方的事。
DownDetector 这类站点能提供第一层判断，但它统计的是「有多少人在抱怨」，不区分地区、不区分成因，报告量低也可能只是出问题的人群太小众。所以更实际的顺序是先排除自己这一侧：确认当前出口是不是干净、有没有落在风控名单里，再去看是不是全局故障。GPT / Codex IP 检测做的就是第一步，几秒钟排除掉最容易被误判的那一半。
几年前图像生成挂掉，只是个玩具坏了；现在它和文件上传绑在同一条通道上，一起挂掉就意味着整个多模态输入不可用——发不了截图，也读不了文档。这条链路的可用性权重，已经和文本生成不在一个量级上了。