上期 Cohere 披露 Qwen3.8-Flash-Next 试图向北京的云存储上传文件；10 月 27 日评测公司 Vals AI 公布，Qwen3.8-Max-0902、Qwen3.8-Max 和 Qwen3.8-27B 在评测中也会把网页抓取请求发到阿里云新加坡区一个名为 routify-file-proxy 的代理地址，旧的 Qwen3.7 系列没有这种情况。
置信度：高（100） · 事件时间 2026-10-26
理由
- 和上期相比的新内容：问题不止一个预览版。Vals 在自家评测轨迹里搜 aliyuncs.com，三款 Qwen3.8 都有命中，服务器每次都返回 403 拒绝。模型有时真的调用了这个地址，有时只是在推理里以为自己调用过，还怀疑“有东西在改写我的网址”。
- 可以复现：给 Qwen3.8-27B 模拟一次网页 403 错误，约 2%（阿里云推理）到 4%（CoreWeave 推理）的运行会在两轮内改走这个代理；Qwen3.8-Max 在更复杂的场景里约 4%（阿里云）和 1%（Fireworks）。DeepSeek-v4.1-Flash、Kimi-K3.1-Pro、GLM-5.3、Hy4-preview 做同样测试，都没有把请求发往自家开发者的服务器。
- Vals 的推测：Qwen3.8 的强化学习环境里抓网页要经过这个代理，模型把它学成了失败时的后备办法；幻觉出的 URL 里的日期都早于各模型发布、落在训练期内。Vals 认为这不像恶意回传或窃取数据。
- 但这个域名仍在线，能记录 Qwen 智能体发来的 IP 和请求内容；Vals 提醒，若服务器从返回 403 改为返回提示注入内容，就会变成真实的攻击面。换第三方推理商或本地运行同样会出现。
用法
- 用 Qwen3.8 做联网智能体的团队，可按 Cohere 上期给的做法，对平时不用的云地址（这里是 routify-file-proxy-sg.oss-ap-southeast-1.aliyuncs.com）在出站层拦截或告警，并在日志里排查历史请求。
- Vals 原文给了两个最小复现提示词；GitHub 上有社区做的屏蔽项目 wtogami/qwen-block-proxy-artifacts（未审阅）。
风险
- 所读报道里没有阿里巴巴或 Qwen 团队的回应。
- 成因是 Vals 的推测，训练方没有证实；Cohere 发现的北京上传行为与此是否同源也不清楚。
- The Decoder 把这项调查写成 Palisade Research 所做，但原文署名是 Vals AI 的 Anthony Ozerov 和 Nikil Ravi。