2026 Runway 웹·Gen 모델 지연? Clash CDN·계정 도메인 분류 실측 절차

① 왜 Runway는 「AI 영상 한 줄」RULE-SET으로 끝내기 어렵나

Runway의 웹 클라이언트는 제품 루트 도메인만 보고 판단하기 어렵습니다. UI 번들·설정·히스토리·모델 선택 화면에 쓰이는 자바스크립트, Gen 프리뷰·타임라인·썸네일을 실어 나르는 미디어·객체 저장소 경로, 실시간 진행 상태를 받는 WebSocket 또는 스트리밍 API, 그리고 계정 세션·OAuth·소셜 로그인 리다이렉트가 거치는 인증 호스트가 각각 다른 접미사로 갈라지는 패턴이 흔합니다. 그래서 범용으로 넓힌 「생성형 AI」 RULE-SET만 켜 두면 “메인 페이지만 PROXY인데 자산·WS는 DIRECT로 떨어진다”는 식으로 경로가 엇갈릴 수 있습니다. 규칙 문법이 익숙하지 않다면 사용자 정의 규칙에서 rules와 proxy-groups 이름을 먼저 맞추는 편이 실수를 줄여 줍니다.

서비스 엔드포인트는 점검·리전·기능 플래그에 따라 도메인이 바뀔 수 있으므로, 이 글의 후보 목록은 출발점이며 최종은 본인 환경의 연결 로그에 찍힌 SNI·호스트로 확정해야 2026년에도 재현 가능한 분류가 됩니다.

② 증상을 네 덩어리로 나누기: 웹 셸·Gen 파이프라인·계정·CDN

같은 「안 된다」라도 가설이 다릅니다. 아래처럼 쪼개 두면 로그와 1:1로 대응시키기 쉽습니다.

• 웹 셸만: 랜딩·대시보드 뼈대는 보이는데 버튼 반응·설정 패널만 비정상 → 스크립트 번들·구성 API 호스트 누락
• Gen·프리뷰만: 업로드는 되거나 대기 표시만 있고 결과가 오지 않음 → 작업 큐·WS·전용 API 접미사 누락 또는 UDP/QUIC과 겹침
• 로그인·세션만: 이메일·소셜 로그인 후 리다이렉트가 끊기거나 세션 쿠키가 다른 호스트로 분산 → OAuth·계정 축 DOMAIN 추가
• 미디어·정적 자산만: 텍스트 UI는 빠른데 프리뷰·움짤·파형만 느림 → CDN·객체 스토리지 접미사를 같은 정책으로 묶었는지 확인

Sora 튜토리얼은 OpenAI 공통 인증·콘텐츠 업로드 호스트 비중이 크고, Midjourney는 이미지 그리드·결제 파트너 패턴이 더 두드러집니다. Runway는 실시간 생성 상태와 미디어 파이프라인이 겹치므로 「한 제품 이름」으로만 RULE-SET을 고르면 빈 구멍이 남기 쉽습니다.

③ Clash 연결 로그에 자주 쓰는 Runway 계열 출발점(반드시 본인 로그로 검증)

아래는 규칙 후보이며 실제 서비스·계정 유형·리전에 따라 추가·변경·삭제될 수 있습니다. 최소한 제품 웹 진입점으로 쓰이는 runwayml.com·app.runwayml.com 류가 Clash 로그에 직접 뜨는지 먼저 확인하세요. 이어서 브라우저 개발자 도구의 Network에서 fetch·ws·media 탭에 찍힌 다른 호스트를 DOMAIN-SUFFIX로 한 줄씩 쌓는 방식이 안전합니다. 대용량 미디어가 HTTP/3를 쓰는 환경에서는 UDP·TUN·스니핑 이슈가 겹쳐 보일 수 있으니 TUN·DNS 글 순서와 병행하는 것이 좋습니다.

• 제품 웹·앱 셸: runwayml.com, www.runwayml.com, app.runwayml.com 및 스크립트가 실제로 물고 있는 서브도메인
• 계정·세션: 로그인 플로우에 따라 OAuth 제공사·제품 자체 계정 호스트가 추가될 수 있음
• 생성·작업 상태: REST·스트림·WS 이름이 분리되어 있으면 각각 규칙에 포함
• 미디어·CDN: 프리뷰·세그먼트 다운로드에 붙는 CDN 접미사(실제 요청 URL 기준)
• 결제·플랜(해당 시): Stripe 등 게이트웨이가 끼면 조직 정책에 맞춰 PROXY 또는 DIRECT로 분리

거대 공유 RULE-SET만 믿기보다, 실패한 요청의 호스트 이름을 기준으로 최소 접미사를 추가하는 편이 국내 직통·사무실 직통과의 충돌을 덜 냅니다. GEOIP 직연결 줄이 앞에 있으면 의도와 다른 정책이 먼저 매칭될 수 있으니 우선순위는 아래 ⑤와 함께 봅니다.

④ 최소 규칙 예: 제품 뿌리 + (로그에서 확인한) Gen·CDN·계정 한 줄

아래는 개념 YAML입니다. PROXY는 구독 프로필의 프록시 그룹 이름으로 바꾸고, MATCH는 본인 기본 정책에 맞게 조정하세요. OAuth·결제 줄은 로그와 약관을 보고 빼거나 별도 그룹으로 나눌 수 있습니다.

rules:
  # Runway — verify every SNI/host in YOUR logs; names change with product updates
  - DOMAIN-SUFFIX,runwayml.com,PROXY
  - DOMAIN-SUFFIX,runway.com,PROXY
  # Add from Network tab / Clash logs, e.g. media CDN object hosts
  # - DOMAIN-SUFFIX,example-cdn.invalid,PROXY
  # Optional: OAuth / auth provider hosts if login chain breaks (verify)
  # - DOMAIN-SUFFIX,accounts.example.invalid,PROXY
  - MATCH,DIRECT

cdn·static·assets·storage 류 접미사가 로그에 따로 찍히면 같은 그룹이어도 DOMAIN-SUFFIX로 명시하는 편이 부분 누락을 줄입니다. 아무 규칙에도 안 걸릴 때는 잠시 MATCH,PROXY로 노드 자체가 살아 있는지부터 가른 뒤 다시 좁히는 순서가 안전합니다. 프록시 그룹을 둘로 나누는 구조는 프록시 그룹 가이드를 참고하세요.

⑤ RULE-SET을 쓸 때: 공유 셋 위에 “개인 한 줄”이 먼저 먹히는지

구독 프로필이 rule-providers로 AI·해외 RULE-SET을 끌어오는 구조라면, 로컬 rules에서 runwayml.com 전용 줄이 의도한 대로 먼저 매칭되는지 연결 흐름으로 확인해야 합니다. Clash rules는 위에서 아래로 읽고 첫 매칭이 최종 정책입니다. GEOIP나 범용 RULE-SET이 앞에 있으면 제품 전용 줄이 사실상 죽은 코드가 될 수 있고, 너무 아래에 두면 이미 MATCH에 걸려 끝나기도 합니다. 프로필 백업 후 한 줄씩 위·아래로 옮기며 재현해 보는 편이 디버깅에 유리합니다.

긴 목록을 중복 관리하기 싫다면 rule-providers에 자체 yaml을 올려 RUNWAY_STACK 같은 이름으로 불러올 수도 있지만, 실제 로그에 맞춘 최소 집합을 권장합니다. Clash 입문 튜토리얼에서 프로필 불러오기와 규칙 적용 순서를 먼저 익히면 이 절을 적용하기 쉬워집니다.

⑥ DNS: fake-ip, DoH, “왜 이 IP지?”로 보이는 이유

증상이 순수 지연이 아니라 간헐적 이름 실패나 한 사이트만 엉뚱한 주소로 붙는 것처럼 보인다면 DNS 쪽을 의심합니다. fake-ip를 켜면 앱이 보는 A 응답과 코어가 규칙 매칭에 쓰는 흐름이 어긋나 보일 수 있고, OS·브라우저 DoH가 동시에 켜 있으면 Clash dns: 블록과 응답 경쟁이 납니다. Linux에서 스텁 리졸버 이슈는 Linux·systemd-resolved 글과 함께 보면 후보를 빨리 좁힐 수 있습니다.

노드 선택은 지역 라벨만 보지 말고 동일 시간대 RTT·손실·서비스가 안내하는 지원 리전을 함께 봅니다. 클라이언트 측 정책 제어가 필요하면 Clash와 VPN 비교도 참고하세요. 다만 계정·결제·본인 인증은 출구 IP 변화가 리스크로 이어질 수 있으니 공지·FAQ에 맞는지 스스로 확인하세요.

⑦ Rule·Global·TUN과 병행할 때의 체크 순서

처음 재현할 때는 Global로 잠시 올려 노드 품질이 정상인지 가른 뒤, Rule로 내려와 분류를 촘촘히 잡는 순서가 시간을 아껴 줍니다. 시스템 프록시만 켠 브라우저와 TUN이 가상 NIC로 끌어오는 앱은 겹치는 범위가 다릅니다. 회사 PC에서는 사내 VPN·보안 에이전트와 충돌할 수 있으니 IT 정책을 우선합니다.

⑧ 실측 절차(요약): 웹·Gen·계정·회귀를 한 루프로

1. 백업: 프로필 내보내기로 현재 YAML을 저장합니다.
2. Rule 모드에서 선택한 그룹과 위쪽 GEOIP·RULE-SET이 Runway 전용 줄보다 먼저 이기지 않는지 확인합니다.
3. 브라우저로 제품에 로그인한 뒤 Gen 작업을 한 번 돌려 보고, 개발자 도구·Clash 로그에 뜨는 호스트를 메모합니다.
4. WebSocket·스트리밍 요청이 따로 보이면 해당 접미사를 같은 PROXY 그룹으로 묶습니다.
5. 로그인만 실패하면 OAuth·계정 호스트 줄을 추가하거나 임시로 경로를 좁혀 비교합니다(보안·약관은 본인 판단).
6. 수정 후 국내 뱅킹·사내 포털이 의도대로 DIRECT인지 회귀 확인합니다.

클라이언트·버전을 맞출 때는 다운로드 페이지에 안내된 설치 흐름을 따르면 문서·스크립트와 흐름이 맞추기 쉽습니다.

⑨ 정책·보안·약관

이 글은 합법적 범위에서 연결 품질·분류 규칙을 기술적으로 설명하는 것이며, 특정 지역 정책을 우회하라는 뜻으로 읽혀서는 안 됩니다. 서비스 이용 가능 지역·플랜·결제 수단은 공식 안내를 따르고, 기업 환경에서는 IT 부서 규정을 우선합니다. 설치 패키지 안내는 다운로드 페이지를, 소스·이슈는 GitHub 등을 목적에 맞게 나누어 두는 것이 독자에게 혼선이 적습니다.

⑩ 정리: Runway는 “웹 + 미디어 CDN + 계정 + Gen 파이프라인”을 한 세트로 보라

2026년에도 Runway는 영상 AI 검색에서 자주 등장하지만, Clash로 관측 가능한 측면에서는 도메인 누락, DNS·fake-ip·DoH 엇갈림, rules 안에서의 우선순위, 노드 품질이 한꺼번에 겹쳐 체감이 갈립니다. Sora·Midjourney 튜토리얼은 제품별로 도메인 묶음이 달라 이 글의 절차는 출발 선으로만 쓰고 본인 로그로 완성하는 것이 맞습니다. 전역 터널보다 호스트 단위 분류가 장기 운용에 잘 맞는 경우가 많습니다. → Clash를 무료로 내려받고, Runway용 도메인 분류·DNS·노드 선택을 맞춰 보세요.