对照实验：同一时刻、同一账号、同一接口，只换来源
腾讯自家 URL（vcg-prod-….cos.ap-guangzhou） → 提交成功 → DONE，产物拿到 ✅
我们的域名（media.windup.xin） → DownloadError → ServerError → … ❌
两次提交相隔不到一分钟。上游是好的 —— 对自家 URL 一次就过。
从我们这边看，那个域名完全正常
HEAD 200 18366000 字节 0.18s
Range 1MB 206 拿到 1048576 字节 0.40s
无 User-Agent 的 GET 200
Server: openresty Content-Type: model/gltf-binary Accept-Ranges: bytes
公网下载速率 4.92 MB/s → 18MB 约需 4 秒
不是 URL 坏了、不是文件太大（17.5MB，上游硬上限 60MB，归档里 15.2MB 成功过）、不是缺 Range 支持、不是 WAF 拦无 UA 请求。
结论
问题在**「腾讯的下载器从我们这个域名取文件」**这一跳。原因我们这一侧看不到 —— 可能是跨网、可能是对端限速、可能是它对某类源站的超时设置。
今天上午同一个 URL 成功过一次（JobId=1484843892775575552），所以不是硬性阻断，是成功率明显偏低。
这改变了 #860 的定位
我原本把云到云当成「省掉每资产约 36MB 中转」的优化。现在看它是正确性问题：
- 走我们的域名：腾讯要从公网拉 18MB，成功率不稳
- 走腾讯自家 URL：同厂同区，实测两次都一次过
要做什么
相关
对照实验：同一时刻、同一账号、同一接口，只换来源
两次提交相隔不到一分钟。上游是好的 —— 对自家 URL 一次就过。
从我们这边看，那个域名完全正常
不是 URL 坏了、不是文件太大（17.5MB，上游硬上限 60MB，归档里 15.2MB 成功过）、不是缺 Range 支持、不是 WAF 拦无 UA 请求。
结论
问题在**「腾讯的下载器从我们这个域名取文件」**这一跳。原因我们这一侧看不到 —— 可能是跨网、可能是对端限速、可能是它对某类源站的超时设置。
今天上午同一个 URL 成功过一次（
JobId=1484843892775575552），所以不是硬性阻断，是成功率明显偏低。这改变了 #860 的定位
我原本把云到云当成「省掉每资产约 36MB 中转」的优化。现在看它是正确性问题：
要做什么
rawurl:落点（那段代码是后加的）—— 它们只能走退路，要么接受低成功率，要么重建相关