OpenRouter가 자꾸 타임아웃? Clash로 openrouter.ai·API 도메인 분할과 노드 실측 절차

OpenRouter와 개발자 프록시 맥락

OpenRouter는 여러 공급자 모델을 한곳에서 호출할 수 있게 해 주는 대표적인 모델 라우팅·집계 API 플랫폼으로, 2026년에도 “하나의 키로 여러 모델”을 쓰려는 개발자·에이전트 도구 체인에서 자주 언급됩니다. 공식 웹·대시보드는 브라우저에서 열리는데, curl·IDE 플러그인·백엔드에서만 API 타임아웃이 반복된다면 원인은 단순 차단이 아니라 경로 분리(일부 호스트만 느린 노드·DIRECT·잘못된 DNS)인 경우가 많습니다. 이 글은 openrouter.ai와 그 하위 API 엔드포인트를 Clash·Mihomo 분할 규칙으로 묶고, TLS·DNS·규칙 순서를 역추적하는 실측 순서에 초점을 맞춥니다.

우회를 조장하지 않으며, 직장·학교 정책과 서비스 약관·현지 법규를 지키는 범위에서, 이미 합법적으로 프록시를 사용할 수 있는 환경을 전제로 기술적으로 정리합니다.

참고: OpenRouter는 CDN·하위 도메인·엔드포인트 구성을 바꿀 수 있습니다. 아래 DOMAIN-SUFFIX 목록은 출발점이며, 실패한 요청의 호스트를 개발자 도구·앱 로그·프록시 로그에서 확인한 뒤 한 줄씩 보강하는 것이 가장 정확합니다.

Cursor IDE 가이드와 겹치지 않게: openrouter.ai 축

저장소의 Cursor IDE 분할 가이드는 cursor.sh·cursorapi.com 등 에디터 생태계 호스트에 맞춰져 있습니다. 반면 OpenRouter는 브랜드 도메인이 openrouter.ai이고, 클라이언트가 설정하는 베이스 URL도 보통 이 축에 머뭅니다. IDE 안에서 OpenRouter를 쓰더라도, 실제 소켓은 openrouter.ai로 나가므로 규칙을 Cursor 전용 그룹에만 두면 API만 빠지는 불일치가 생길 수 있습니다. 본문에서는 OpenRouter 도메인·API만 별도 전략 그룹으로 두는 패턴을 권장합니다.

ChatGPT·Claude처럼 특정 공급자 호스트에 직접 붙는 경우와 달리, OpenRouter는 내부적으로 모델 라우팅 뒤에 다른 클라우드·엔드포인트로 이어질 수 있습니다. 그래도 클라이언트 입장에서 먼저 안정적으로 붙어야 할 곳은 openrouter.ai 측 TLS 세션이므로, 우선 이 축의 분할 규칙·노드 품질을 맞추는 것이 타당합니다.

타임아웃·TLS·DNS에서 의심할 패턴

다음 증상이 겹치면 규칙 매칭 로그와 실제 요청 호스트를 동시에 보세요.

  • 웹 대시보드는 되는데 API만 실패: HTML·정적 자산은 캐시·국내 경로로 충분히 받았으나, /api/ 등 API 경로만 다른 정책 그룹으로 나가는 경우입니다.
  • 연결은 되다가 응답 전에 끊김: 장기 연결·스트리밍에서 패킷 손실이 큰 노드, 세션 제한, 또는 중간 MITM·검열 장비를 의심합니다. TLS 핸드셰이크 단계에서 멈추면 SNI·인증서 체인 이슈도 함께 봅니다.
  • 터미널만 실패하고 브라우저는 성공: 시스템 DNS·프록시 환경 변수·TUN 미적용으로 앱이 Clash 밖에서 이미 IP로 붙는 경우입니다.

복사해 쓰기 좋은 openrouter.ai 후보 목록

실측된 FQDN을 우선하되, 초기 프로필에 넣기 좋은 후보는 다음과 같습니다.

  • 서비스 루트: openrouter.ai — DOMAIN-SUFFIX,openrouter.ai 한 줄이면 api.openrouter.ai·www.openrouter.ai 등 하위를 넓게 덮습니다.
  • 문서·OAuth·결제: 계정 연동이 늘어나면 로그인·결제 게이트웨이 호스트가 추가될 수 있으니, 네트워크 탭에서 실패 URL을 그대로 DOMAIN 또는 DOMAIN-SUFFIX로 올립니다.
  • CDN·정적 자산: 번들·이미지가 별도 호스트로 나가면 UI는 부분적으로만 깨질 수 있습니다. 실패한 요청의 호스트를 규칙에 포함하거나 동일 OpenRouter-API 그룹에 둘지 판단합니다.

지나치게 넓은 접미사(특정 퍼블릭 클라우드 전체 등)는 다른 업무 트래픽까지 끌어올 수 있으니, 관측된 이름을 기준으로 최소 확장을 권장합니다.

전략 그룹과 rules: 예시

개념용 축약 YAML입니다. 그룹 이름·프록시 목록은 구독에 맞게 바꾸고, 도메인 줄은 본인 환경 로그에 맞게 덧붙이세요.

YAMLproxy-groups:
  - name: "OpenRouter-API"
    type: url-test
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50
    proxies:
      - DIRECT
      # ... 지연·손실이 낮은 해외 노드 ...

  - name: "Proxy"
    type: select
    proxies:
      - DIRECT
      # ... 일반 구독 노드 ...

rules:
  - DOMAIN-SUFFIX,openrouter.ai,OpenRouter-API
  # 네트워크 탭·로그에서 확인한 추가 호스트를 DOMAIN 또는 DOMAIN-SUFFIX로 삽입
  # GEOIP·MATCH·거대 RULE-SET보다 위에 두세요

url-test 헬스 URL은 구독 제공자 권장 주소로 바꿀 수 있습니다. 중요한 점은 짧은 헬스가 통과해도 긴 컨텍스트·스트리밍 응답은 다른 특성을 가질 수 있다는 것입니다. OpenRouter-API 그룹에는 일반 웹 서핑용과 다른 리전·다른 라인을 두고 비교 실험해 보세요.

모델 라우팅과 노드 선택

OpenRouter는 요청한 모델 ID에 따라 내부적으로 다른 업스트림으로 연결할 수 있습니다. 그렇다고 해서 클라이언트가 SNI를 바꿀 수 있는 것은 아니므로, 사용자가 제어하는 첫 구간은 여전히 openrouter.ai입니다. 증상이 특정 모델에서만 난다면 (1) 해당 모델이 일시적으로 느린 것인지, (2) 동일 요청을 다른 노드에서 반복했을 때도 같은지로 노드 의존성을 분리합니다. 스트리밍(stream: true)은 장기 TCP에 더 민감하므로, 다운로드 속도만 보지 말고 지연 변동·끊김을 기록하세요.

DNS·fake-ip와 규칙이 엇갈릴 때

DNS는 DOMAIN-SUFFIX가 기대대로 적용되는지를 좌우합니다. enhanced-mode: fake-ip를 쓰면 대부분 호스트명 단계에서 도메인 규칙이 먼저 매칭되지만, 앱이 Clash 밖에서 이미 IP로 소켓을 열면 DOMAIN 계열이 건너뛰어질 수 있습니다. CLI·백엔드만 실패할 때는 TUN 모드로 트래픽을 커널에 태우는 방안과 함께 검토하세요.

DoH·OS DNS와 Clash DNS가 동시에 동작하면 “규칙은 맞는데 실제 질의는 다른 리졸버”가 되기도 하므로, 한 번에 한 축만 바꿔 가며 확인합니다. fake-ip-filter는 증상이 있을 때만 최소한으로 추가하세요.

GEOIP·RULE-SET이 OpenRouter 규칙을 덮어쓸 때

Clash 규칙은 위에서 아래로 첫 일치에서 종료합니다. GEOIP,KR,DIRECT나 광범위한 MATCH를 목록 상단에 두고 그 아래에 openrouter.ai 줄을 적으면 아래 줄은 실행되지 않습니다. OpenRouter용 DOMAIN·DOMAIN-SUFFIX는 해당 GEOIP·MATCH보다 위에 두세요. 일반 원리는 규칙 분할 가이드와 같습니다.

구독 템플릿의 RULE-SET이 특정 TLD나 키워드를 다른 정책으로 보내는 경우도 있습니다. 대시보드 로그에서 어떤 규칙에 매칭됐는지 확인하고, 로컬 예외를 위로 올리거나 provider 순서를 조정하세요.

실측 점검 순서: 로그·연결·노드 전환

  1. 브라우저 개발자 도구·앱 로그로 실패·지연한 요청의 호스트를 적어 규칙에 반영합니다.
  2. Clash 로그에서 매칭된 규칙·정책 그룹이 OpenRouter-API(또는 본인이 지정한 이름)인지 확인합니다.
  3. 동일 요청을 OpenRouter-API 그룹 안에서 노드만 바꿔 반복해 출구·리전 의존성을 좁힙니다.
  4. 터미널에서 프록시를 강제한 채 curl -v 등으로 TLS 핸드셰이크 단계까지 도달하는지 봅니다. 여기서 멈추면 SNI·인증서·중간 장비를 의심합니다.
  5. 증상이 특정 시간대에만 나타나면 노드 풀 혼잡과 서비스 측 지연을 구분합니다.

주의: 출처가 불분명한 원격 rule-set은 악성 규칙이 섞일 수 있습니다. API 키·프롬프트를 다루는 프로필일수록 신뢰할 수 있는 소스만 사용하세요.

마무리

OpenRouter는 openrouter.ai 한 줄로 끝나지 않고, 대시·계정·정적 자산 등 주변 호스트가 늘어날 수 있습니다. “화면은 되는데 API만 타임아웃”은 분할 규칙과 전략 그룹이 API 경로와 어긋났을 때 흔히 나옵니다. DOMAIN-SUFFIX로 서비스 축을 묶고 전용 그룹에 할당한 뒤, DNS·규칙 순서·노드 품질을 한 번에 맞추면 원인 분석이 단순해집니다.

일체형 VPN과 비교했을 때 Clash·Mihomo 계열은 표현력이 높아 개발자 API 트래픽을 분리하기에 적합하지만, 로그를 읽고 순서를 관리할 책임도 함께 따라옵니다.

설치와 프로필 반영 절차는 문서·튜토리얼을 참고하시고, 규칙을 적용할 준비가 되었다면 Clash를 무료로 다운로드하여 본문 예시를 바탕으로 proxy-groups와 rules만 조정해 보시길 바랍니다. OpenRouter 전용 호스트 묶음을 한 덩어리로 정리해 두면 이후 엔드포인트가 늘어날 때 목록만 덧붙이면 됩니다.