这类问题我又碰上了一次。转写接口支持直接传音频 URL，传入对象存储的地址后返回 400，原文 unable to download audio file，浏览器里打开同一链接能正常播放。
第一反应是「存储桶设置了 Referer 白名单」，验证下来不成立。
排查方向其实有限，先把可能性排一排。链接返回 302 跳转，转写服务不跟随；签名 URL 已过期，服务端拿到的是 403 页面；返回的 Content-Type 不是音频类型。
先看链接的响应码和跳转
curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' "https://bucket.oss-cn-hangzhou.aliyuncs.com/a.mp3"然后换成带签名的直链并延长有效期
python -c "print('sign_url(expires=3600, method=\"GET\")')"接着确认 Content-Type 是 audio 开头
curl -sI "$AUDIO_URL" | Select-String Content-Type本地下载后改用文件上传验证
curl -s https://api.openai.com/v1/audio/transcriptions -H "Authorization: Bearer $OPENAI_API_KEY" -F file=@a.mp3 -F model=whisper-1手上没有现成的复现脚本，就照着线上请求手工拼了一个。
报错是间歇性的，我蹲守了半小时才抓到一次完整现场。
改完先别撤，确认这几项。带签名的直链能被服务端拉取，转写返回完整文本，与本地文件上传的结果一致。
提醒一点。服务端拉取不会执行跳转和登录，URL 必须是可直接 GET 到音频字节的地址。拖得越久，排查成本越高，因为现场状态会被后续操作覆盖。