알리바바 통의 Qwen과 DashScope API가 버벅일 때: Clash 분류 규칙과 DNS 최적화 (2026)

증상: 웹은 되고 API만 끊길 때

Qwen 웹 UI는 콘솔 브라우저 세션 하나로 불러오지만, DashScope REST·프롬프트 스트리밍 같은 API는 보통 서로 다른 FQDN에 붙습니다. 공식 문서·샘플에서 자주 예로 드는 dashscope.aliyuncs.com 일대는 컨트롤 플레인에 가까운 축으로 이해하면 되며, 브라우저에선 잘 보이지 않는 인증 헤더(X-DashScope-… 등)·리전 코드가 붙는 요청이라, TCP 세션 특성도 간단히 설명되는 웹 패턴과 동일하지 않습니다. 그래서 GEOIP CN → DIRECT 한 줄 때문에 API만 의도치 않게 DIRECT로 새어 나가거나 반대로, GFW 밖 회선만 믿던 정책이 알리바바 CN 리전 호스트에만 부적합한 경우가 있습니다.

또한 브라우저는 운영체제 시스템 프록시를 따라가지만, 로컬 python, 컨테이너, CI 잡 안의 클라이언트는 프록시를 모르고 직접 나가 증상이 한쪽 파일에만 보이는 경우가 있습니다. 모든 프로세스에 동일한 파이프를 쓰려면 TUN 모드나 환경 변수 수준까지 맞춰야 하므로, 문서 허브와 fake-ip-filter 글도 함께 보시길 권합니다.

글의 범위: 통의 「모델 리뷰」가 아님

토큰 단가·지원 모델 ID·컨텍스트 길이는 공식 매뉴얼과 릴리스 노트가 가장 빠르게 갱신됩니다. 여기서 반복해서 말할 것은 패킷이 어디로 라우팅되는지입니다. Clash에서 DOMAIN·DOMAIN-SUFFIX 매칭이 기대와 다르면, 이름은 맞아도 출구가 다른 정책 그룹을 타는 상황이 생깁니다. Kimi·DeepSeek 같은 시리즈와 동일하게, 우리는 네트워크 엔지니어링만 다룹니다.

1호스트 목록 만들기(Qwen 웹 대 DashScope)

정답표를 외워 붙여 넣기보다, 사용 중인 브라우저 개발자 도구 네트워크 패널에서 실제 호스트 문자열을 복사하는 것이 안전합니다. Qwen 채팅 웹은 접속 국가·계정 종류에 따라 tongyi.aliyun.com 또는 이후 명칭 변경된 채널별로 SPA가 깔리고, 거기에서 로드되는 CDN·통계 빈이 추가됩니다.

반면 DashScope 호출에는 SDK가 선택한 endpoint가 그대로 찍히니, 타임아웃 시 에러 문자열 근처에 붙어 있는 연결 문자열 전체를 기록하세요. .aliyuncs.com 계열 접미사는 서비스가 늘 때마다 늘어납니다. 사용자 정의 규칙 파일로 RULE-SET처럼 유지하면, 업스트림 앱 업데이트 이후 새 호스트만 덧대기 쉽습니다.

2분류 규칙 초안 예시

아래는 그림 예시입니다. PROXY_QWEN 자리에는 본인의 프록시 그룹 이름을 넣고, 이미 존재하는 RULE-SET, MATCH와 순서 관계만 다시 검토해야 합니다. GEOIP 혹은 국가 블록 규칙이 앞쪽에 놓여 있어 알리바바 호스트 이름을 가리키기 전에 잡히는지가 핵심입니다 — 구체 순서 패턴은 규칙 우선순위 글을 따라가면 헷갈리지 않습니다.

# Minimal illustration — replace PROXY_QWEN with your policy group
rules:
  - DOMAIN-SUFFIX,dashscope.aliyuncs.com,PROXY_QWEN
  - DOMAIN-KEYWORD,dashscope,PROXY_QWEN
  - DOMAIN-KEYWORD,tongyi,PROXY_QWEN
  - DOMAIN-KEYWORD,qwen,PROXY_QWEN
  - MATCH,DIRECT

웹 전용 라인과 API 전용 라인을 나눌 때

CDN 직통이 더 빠른 구간까지 모두 같은 프록시로 몰아넣으면 체감은 나아질 수 있지만 반대도 있습니다. 디버깅 단계에서는 먼저 동일 한 그룹으로 통일해서 “경로 불일치”를 제거하고, 문제가 줄어든 뒤에만 더 세분화하는 접근을 추천합니다. 도메인 단위로 나뉘면 selector만 바꿔도 출구 비교 실험이 쉽습니다.

3DNS·FakeIP·스니퍼 한 축으로

FakeIP를 쓰면 클라이언트가 본 문자열 도메인과, 실제 TCP 레이어에서 스니퍼가 되살린 도메인이 어긋날 여지가 있습니다. Meta/Mihomo에서는 enhanced-mode 설정과 함께 nameserver-policy나 fallback 체인이 한 프로필 안에서 어떻게 정렬되어 있는지를 다시 확인하세요.

업스트림 DoH가 회사 라우터·ISP 쪽에서 랜덤 지연되는 경우에는, 브라우저와 같은 OS에서 직접 dig·프로필 DNS 로그 간 응답을 비교해 보면 “DNS만 이상하게 느리다” 같은 구간을 빨리 분리합니다. 깊게 다룰 때는 Meta 코어 DNS 유출 방지로 구체 패턴으로 이동하시면 됩니다.

4정책 그룹·노드 품질과 장시간 토큰

API 스트리밍처럼 TCP 타임아웃이 길어지면, url-test 그룹의 짧은 tolerance interval 때문에 중간에 다른 노드로 갈아탄 상태가 되어 연결이 깨진 것처럼 보일 때가 있습니다. 이럴 때는 실험적으로 DashScope 전용 selector(수동 선택) 또는 지정 단일 노드로 고정했을 때 호전되는지부터 보세요. 패킷 손실이 큰 링크는 지연 수치가 낮아도 체감이 나쁩니다.

5검증: curl, SDK 로그, Clash 연결 기록

변경은 한 번에 한 겹씩입니다. 먼저 curl -v로 TLS 핸드셰이크 구간까지 시간을 재고, 그다음 Clash 연결 로그에서 같은 호스트가 어떤 rule과 policy를 탔는지 확인합니다. 시스템 프록시 ON vs TUN ON을 번갈아 비교하면 “프로세스가 프록시를 모른다”는 가설을 빠르게 배제할 수 있습니다.

다른 국산·클라우드 LLM 글과의 관계

절차는 블로그 안의 같은 시리즈입니다. 단지 제품군 이름만 바뀌었을 뿐, 근본 패턴(웹 호스트≠API 호스트, DNS와 규칙 정합성)은 같습니다. 豆包(두바오)처럼 국내 퍼블릭 클라우드에 붙는 경우도 방법론이 비슷하니, 교차 검색해서 읽어도 좋습니다. 전반적 옵션 지도가 필요하면 설정 허브를 함께 보세요.

맺음말

Qwen과 DashScope처럼 글로벌 개발자에게도 선택지로 제시되는 알리바바 클라우드 API는 엔드포인트 종류만으로도 회선 선택이 크게 달라집니다. Clash 분류 규칙을 한 번이라도 깔끔히 적어 두면, 일상적인 웹 테스트와 자동 배치 호출이 같은 패밀리를 공유하면서 일어나는 혼선을 줄이는 데 실질적입니다. 패키지는 공식 허브를 통한 받기가 깔끔하고, GitHub에는 오픈소스 본편 확인용으로 접근하는 분리 패턴 이전에 블로그에서 안내했듯 적용 가능합니다.

→ 클라이언트는 사이트에서 무료로 내려받아, Qwen·DashScope 포함 AI 워크로드를 하나의 규칙 트리로 정돈해 보세요