1 왜 «한 키·여러 모델»은 프록시만으로 끝나지 않는가
OpenRouter는 OpenAI 호환 엔드포인트를 제공해 다중 모델 API를 한 주소에서 고르게 하지만, 운영 측면에서는 여전히 브라우저 세션(로그인·설정·크레딧)과 백엔드 호출(토큰 청구·스트리밍)이 섞입니다. 문서에 적힌 베이스 URL이 https://openrouter.ai/api/v1처럼 동일 레지스트라 아래에 있어도, 자산 로딩·서드파티 스크립트·결제·상태 페이지는 다른 서브도메인이나 외부 CDN으로 이어질 수 있습니다. 그 결과 IDE 플러그인은 프록시를 타는데 브라우저만 직행하거나, 반대로 API만 403이 나는 식의 «절반만 성공»이 생깁니다.
Clash·Mihomo에서 목표는 속도 경쟁이 아니라, Connections 로그에 찍힌 FQDN이 팀이 정한 프록시 그룹으로 일관되게 나가게 만드는 것입니다. 클라이언트가 없다면 다운로드 페이지에서 OS에 맞는 GUI를 고른 뒤 Rule 모드 프로파일을 켜세요.
호스트 목록은 분기·기능 플래그에 따라 바뀔 수 있습니다. 아래 예시는 출발점이며, 실패 직후의 실제 SNI를 한 번 확인하는 것이 가장 안전합니다.
2 대시보드·추론 API·부가 트래픽을 어떻게 나누어 볼 것인가
공개 문서 기준으로 추론 API의 기본 축은 openrouter.ai이며, /api/v1/models·/api/v1/chat/completions 등이 같은 호스트 아래에서 동작하는 패턴이 일반적입니다. 콘솔·키 관리 역시 웹 UI가 같은 도메인 패밀리에 묶여 있어, 첫 설정에서는 DOMAIN-SUFFIX,openrouter.ai 한 줄로 대부분의 사용자 시나리오를 덮을 수 있습니다. 다만 크레딧 충전·결제 안내에서 결제 게이트 도메인이 추가되거나, 정적 자산이 별도 CDN으로 분리되면 규칙만으로는 부족해집니다.
이때 필요한 것이 로그 기반 보강입니다. Mihomo 대시보드나 클라이언트의 Connections 뷰에서 실패 순간의 호스트를 복사해, DOMAIN-SUFFIX 후보로 목록화하세요. 지나치게 넓은 DOMAIN-KEYWORD는 오탐이 나기 쉬우니, 장기 운영에서는 접미사·정규식 규칙을 조합하는 편이 낫습니다. 구독 YAML이 Clash 형식과 다르면 구독 변환 가이드로 맞춘 뒤 규칙을 얹으세요.
3 DOMAIN-SUFFIX와 규칙 우선순위
Clash 분할에서 규칙은 위에서 아래로 매칭됩니다. 거대한 GEOSITE 묶음이나 범용 Rule Provider가 구체 호스트보다 위에 있으면, 의도한 API 프록시 그룹에 도달하기 전에 흡수됩니다. OpenRouter 전용으로 PROXY-OPENROUTER 같은 그룹을 만들었다면, (1) 팀에서 합의한 OpenRouter 접미사 블록을 중간쯤에 두고, (2) 그 아래에 더 일반적인 규칙을 두는 식으로 읽기 쉽게 정렬하세요.
이미 DeepSeek·OpenAI 전용 그룹을 쓰고 있다면, 집계 게이트웨이만 별도 그룹으로 두는 편이 디버깅에 유리합니다. 반대로 지연 차이가 크지 않으면 PROXY-AI-AGG처럼 한 그룹으로 묶어도 됩니다. 중요한 것은 프로파일 안에서 이름과 순서가 동료가 봐도 바로 이해되게 적혀 있는지입니다.
4 Rule Provider로 목록을 버전 관리하기
호스트가 늘어날수록 YAML에 직접 붙여 넣기보다, 사내 Git 저장소에 텍스트 목록을 두고 Rule Provider로 끌어오는 방식이 유지보수에 유리합니다. behavior: classical 목록을 올려 두고 RULE-SET,openrouter-2026,PROXY-OPENROUTER처럼 참조하면, 긴급 한 줄 패치는 수동 규칙으로, 주간 동기화는 Provider로 나눌 수 있습니다. 릴리스 주기가 빠른 다중 모델 API 시즌에는 이 패턴이 특히 편합니다.
개인 보강만 분리하고 싶다면 mixin·구독 덮어쓰기로 팀 베이스 위에 로컬 오버레이를 얹는 방법도 있습니다.
5 YAML 예시 (개념 스니펫)
아래는 병합용 예시입니다. PROXY-OPENROUTER는 본인의 proxy-groups 정의와 이름을 맞추고, 상위 규칙과 충돌하지 않게 순서를 조정하세요. 실제 배포 전에는 반드시 Connections 로그로 검증합니다.
# OpenRouter: dashboard + API share openrouter.ai in typical setups
- DOMAIN-SUFFIX,openrouter.ai,PROXY-OPENROUTER
# If logs show extra subdomains or CDNs, add suffixes explicitly:
# - DOMAIN-SUFFIX,cdn.example.com,PROXY-OPENROUTER
# Prefer FQDN from Connections over wild guesses.
# Keep this block above overly broad GEO / catch-all rules.스트리밍 응답은 긴 세션을 유지하므로, 노드를 자주 바꾸지 말고 한 요청을 끝까지 같은 출구로 보내는 것이 재현성에 유리합니다. 필요하면 url-test·fallback 그룹 전략을 함께 검토하세요.
6 Cursor·GitHub Copilot·CLI와의 프록시 체인
Cursor나 VS Code 확장이 OPENAI_BASE_URL·호환 베이스 URL을 OpenRouter로 바꾸면, 로컬 에디터 트래픽이 곧바로 API 프록시 규칙에 걸립니다. 이때 회사 HTTP 프록시와 Clash 시스템 프록시가 이중으로 겹치면 인증 헤더가 꼬이거나 지연이 커질 수 있으니, 어느 층이 최종 출구인지 한 가지로 정하는 것이 좋습니다. Cursor·Clash 글에서 다룬 것처럼, 확장·내장 터미널·외부 CLI가 서로 다른 경로를 타지 않게 점검하세요.
GitHub Copilot은 별도의 GitHub·Azure 호스트를 사용하므로 OpenRouter와 섞이지 않습니다. 다만 같은 워크스테이션에서 둘 다 쓰면 규칙 우선순위에서 Copilot 관련 접미사가 먼저 소비되는지 확인해야 합니다. Copilot·Clash 글의 호스트 묶음과 본문의 OpenRouter 묶음이 서로 덮어쓰지 않게 순서를 조정하세요.
터미널의 curl·SDK는 환경 변수 없이 DIRECT로만 나가는 경우가 많습니다. 에디터는 프록시를 타는데 CLI만 실패하면, 규칙 문제가 아니라 프로세스 경로 문제일 가능성이 큽니다. 이때는 TUN 모드로 시스템 트래픽을 한 엔진에 넣거나, 터미널에 프록시 변수를 명시하세요.
7 DNS·TUN·시스템 프록시 정렬
규칙이 맞아도 DNS가 ISP 쪽으로 새면 지역 응답이 엇나가 API 프록시 매칭 전에 실패하는 것처럼 보입니다. DoH·FakeIP 가이드에 맞춰 Clash DNS·OS 리졸버·TUN을 정렬하세요. 스트리밍 토큰이 많은 호출에서는 타임아웃 값도 함께 살펴보는 것이 좋습니다.
WSL·Docker 안에서 호출하면 호스트 OS의 프록시 설정과 또 다른 격리망이 생깁니다. 컨테이너가 게이트웨이를 다르게 보면 OpenRouter만 이상하게 느려질 수 있으니, 동일 머신에서 브라우저·컨테이너·네이티브 바이너리의 기본 라우트를 한 번에 그려 보세요.
8 트러블슈팅 체크리스트
- 웹 콘솔은 되는데 API만 401/403: 키·헤더·조직 정책을 먼저 확인하고, 동일 키로 최소 요청을
curl로 재현합니다. - 모델 목록은 되는데 스트리밍만 끊김: 노드 지연·MTU·긴 세션 차단을 의심하고, 다른 노드로 A/B 테스트합니다.
- IDE만 되고 터미널만 실패: 터미널 프록시 환경 변수·TUN 적용 여부를 확인합니다.
- 간헐적 호스트 추가: Connections 로그를 캡처해 Rule Provider PR에 반영합니다.
- 이중 프록시: 회사 프록시 + Clash가 겹치면 헤더·인증이 꼬일 수 있습니다. 한 층만 남깁니다.
9 약관·키 보안·망 정책
연결이 안정되어도 OpenRouter 이용약관·모델별 라이선스·조직 보안 정책은 그대로 적용됩니다. 본문은 합법적인 개발 환경에서의 Clash 분할 구성을 설명할 뿐, 통제된 네트워크를 우회하라는 뜻이 아닙니다. API 키는 저장소에 올리지 말고 비밀 관리 도구에 두세요. 클라이언트 소스는 GitHub 등에서 확인할 수 있으나, 설치 패키지는 사이트 다운로드 페이지를 우선하는 편이 출처 관리에 유리합니다.
10 정리
2026년 집계형 추론 API 흐름에서 OpenRouter는 다중 모델 API를 한 엔드포인트로 묶는 대표 사례입니다. 네트워크 측면에서는 콘솔·추론·부가 호스트가 한꺼번에 얽히므로, Mihomo·Clash로 DOMAIN-SUFFIX·Rule Provider를 정리하고, 에디터·CLI·컨테이너가 같은 정책을 쓰게 시스템 프록시·DoH·FakeIP·필요 시 TUN까지 맞추는 것이 핵심입니다. 단일 벤더 전용 튜토리얼은 기존 ChatGPT·Claude 글을 참고하고, 본 글은 집계 게이트웨이 축에만 초점을 둡니다.
동급 GUI에서 규칙을 저장해 두면 팀원이 같은 Clash 분할로 API 프록시를 재현하기 쉽습니다. Rule 편집기·로그 뷰가 잘 보이는 제품을 고르면 운영 스트레스가 줄어듭니다.
