지난호에서 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 거절을 반환했습니다. 모델은 때로는 실제로 이 주소를 호출했고, 때로는 추론 과정에서 자신이 호출했다고 착각하며 '무언가가 내 URL을 변경하고 있다'고 의심했습니다.
- 재현 가능: 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입니다.
열기 · Vals AI 블로그(1차 조사) · Cohere 블로그(이전 호 1차 테스트 기록) · The Decoder