现场是这样的。图片改存 MinIO 之后把请求从 base64 换成 image_url，接口返回 invalid image url，同一张图内联成 data URL 就能识别，图片地址是内网 10.0.3.21 的域名。
中间走过弯路，把「对象存储返回的 Content-Type 是 binary/octet-stream，被判定不是图片」当成主因，改完现象没变。
这类报错背后常见的原因有几处，逐个排除就行。模型服务在公网侧，要去下载这个 URL，内网域名在它那边解析不到；预签名 URL 的有效期只有五分钟，排队到下载时已经过期；下载被 302 到 https，证书链在服务端不受信任。
从外部网络确认这个地址是否可达
curl -sI https://files.example.com/a.jpg生成有效期覆盖排队的预签名地址
mc share download --expire 30m local/bucket/a.jpg接着核对响应头里的内容类型
curl -sI https://files.example.com/a.jpg | findstr /i content-type末了改用内联作为兜底
python -c "import base64;print(len(base64.b64encode(open('a.jpg','rb').read())))"恢复的判定其实很直接。请求返回 200 且输出能描述图片内容，URL 的 HEAD 状态码为 200、content-type 是 image/jpeg，日志里不再出现 invalid image url。
提醒一点。预签名有效期要大于下载排队时间，公网侧能不能访问要提前验证，别把地址换成 URL 就想当然地认为模型能拿到。监控比日志更早给出信号，事后回看经常能提前半小时发现异常。