OpenRouter와 모델 API가 총 타임아웃처럼 느껴질 때: 2026년 Clash 분류로 통합 게이트웨이 라우팅 안정화

왜 「게이트웨이 전체가 타임아웃」처럼 느껴지는가

OpenRouter에게 요청하면 대부분의 클라이언트는 우선 openrouter.ai 같은 게이트웨이 호스트에 붙고, 그 안에서 선택한 업스트림 모델에 따라 라우팅됩니다. 화면에는 OpenRouter 한 줄이지만 네트워크 레이어에서는 TCP·TLS 세션 장시간 유지, 큰 출력에 따른 긴 바디 스트림, 재시도가 겹치며 “한 번에 많은 변수”가 같은 증상(멈춘 듯 보임·클라이언트 레벨 timeout)으로 수렴하기 쉽습니다.

전역 Global 모드 또는 느슨한 정책 그룹에서 지터 큰 무제한 노드만 골라 쓰면, 속도 테스트 점수는 좋아도 스트리밍·장문 응답에서 브레이크가 납니다. 반대로 DNS 해석만 Clash 바깥에서 끝나 fake-ip 규칙과 어긋나면 “패킷은 나가는데 매칭이 엇갈린다”는 패턴도 나옵니다. 따라서 증상을 한 단어로 뭉개기 전에, SNI가 가리키는 호스트 이름과 실제 선택된 노드 이름을 로그에 남겨 같은 연결 재현을 만드는 것이 첫 번째입니다.

• TCP 핸드셰이크부터 느리다: 노드 회선 또는 경로 선택 문제 가능성↑
• 연결 후 첫 바이트(TTFB)만 길다: 업스트림 처리 지연과 긴 출력 큐까지 의심
• 같은 스크립트가 가끔만 실패: 규칙 순서 묻힘, DNS 경로 불일치, 노드 순환 순간 실패 순

통합 게이트웨이와 업스트림별 직통의 차이

우리 블로그에는 Anthropic Claude·DeepSeek/Gemini처럼 한 벤더 도메인 묶음만 다룬 글이 있습니다. OpenRouter는 그 위에 놓인 공통 라우팅 계층이라, 클라이언트 코드가 업스트림 URL을 노출하지 않는 한 구성하는 사람 입장에서는 openrouter.ai와 해당 API 패스 한 묶음만 믿고 가기 쉽습니다.

게이트웨이 특유의 과제는 한 연결이 사용자 기대 시간보다 오래 버티어야 한다는 점입니다. HTTP/2 또는 스트림 옵션을 켠 라이브러리는 업스트림이 실제 어디든 OpenRouter 종단까지 같은 TLS 연결로 보이지만, 회선 품질과 프록시의 idle timeout 정책이 맞물리면 사용자는 “무슨 업스트림이든 간에 다 느리다”로 경험합니다. Clash에서는 이를 OpenRouter 묶음 전용 그룹 + 보수적인 url-test 간격 또는 고정 선택으로 줄입니다.

분류 규칙으로 OpenRouter 묶음 만들기

Rule 모드에서 게이트웨이 호스트 이름을 MATCH나 넓은 GEOIP보다 위에 두어야 예측 가능한 출구가 됩니다. 이름은 예시로 PROXY_LLM_GATE처럼 다른 개발 글과 겹치지 않게 두면, 나중에 CLI·환경변수 프록시 점검과도 헷갈리지 않습니다.

원격 규칙 제공자(remote rule-provider)를 여러 겹 태운 구독에서는 병합 순서가 아래쪽으로 미는 한 줄의 실수로 로컬 OpenRouter 규칙이 묻힙니다—GUI 미리보기나 코어 로그로 “이 요청은 어디서 매치됐나” 확인하세요. Mixin으로 구독과 수동 노드를 동시에 운영한다면 같은 파일에서 rules 접두 순서까지 함께 점검하는 편이 안전합니다.

# Illustrative rules — rename PROXY_LLM_GATE; extend from logs
rules:
  - DOMAIN-SUFFIX,openrouter.ai,PROXY_LLM_GATE
  - DOMAIN-KEYWORD,openrouter,PROXY_LLM_GATE
  - GEOIP,cn,DIRECT
  - MATCH,PROXY

DOMAIN-KEYWORD가 다른 합법 도메인을 집어 삼키지 않는지 확인한 뒤에만 쓰세요. 실제 실패 호스트만 로그에 찍히면 DOMAIN-SUFFIX로 좁히는 것이 장기적으로 덜 깨집니다. 문서 또는 클라가 사용하는 최종 API 호스트 이름이 업데이트되면 해당 행만 보강하면 됩니다.

DNS·fake-ip·TLS 레이어

규칙을 맞췄는데도 간헐 실패하면 해석 경로를 의심합니다. fake-ip 설정을 쓰는 동안 애플리케이션이 직접 IP로 붙는 경로와 Clash 규칙 엔진이 보는 패킷 경로가 엇갈리면 증상이 “전부 게이트웨이 때문”처럼 보입니다. 절차는 《DNS·fake-ip 점검》을 따르고, OpenRouter 테스트 시에는 동일 재현 요청에 대해 DNS 응답과 코어 매칭 로그 타임스탬프를 나란히 두세요.

브라우저가 보안 DNS(DoH)만 쓰고 OS는 다른 리졸버를 쓰면, 페이지나 스크립트마다 다른 “첫 줄”부터 갈립니다. 개발용 프로파일에서는 잠시 보안 DNS를 끄고 재현해 보거나, Clash 이름 서버 설정을 브라우저와 맞춰 해석 단일화 한 가지만 고르세요. IPv6 AAAA 우선 때문에 예상 외 회선으로 새는 경우도 있으므로 불일치가 의심되면 해당 스택을 잠깐 빼 보는 것도 디버깅에 유효합니다.

노드·정책 그룹: 장기 연결에 맞추기

짧게 말하면 “핑 테스트 1등”이 반드시 스크립트 장시간 실행에서도 최선은 아닙니다. 무제한·낮은 가격 노드 중 일부는 idle 연결을 빨리 끊거나 대역폭 큐 길이가 길어 TTFB 타임아웃을 유발합니다. OpenRouter 전용 그룹에는 가능하면 지터가 적고 TTL이 길게 느껴지는 출구 후보만 넣고, 전역 라이브 테스트와 동일한 간격으로 공격적으로 바꿔 치게 두지 마세요.

url-test·fallback을 붙였다면, 대상 URL을 실제처럼 HTTPS로 살아있는 검사 가능한 엔드포인트 근처로 두고, 간격과 관용치는 장기 연결과 충돌하지 않게 미세 조정합니다. 무엇보다 같은 스크립트가 짧으면 성공하고 길면 실패하면 “노드가 아예 아닐 때”처럼 보이도록 idle·timeout 우선 순위를 높입니다.

관측	의심	다음 행동
동일 명령이 짧게만 성공	연결 시간·바디 길이·idle 타임아웃	더 안정 노드 또는 고정 출구 검토
재시도 폭주 후 전부 타임아웃	429 누락 처리·무한 재요청 버그	코드 backoff·동시 실행 수 제한
브라우저만 되고 curl은 실패	환경변수 미적용·DoH 차이	환경변수 프록시·시스템 프록시 정합 확인

IDE·스크립트·터미널에서의 출구 일치

VS Code·CLI·CI에서 같은 API 호출이라도 각각 다른 프록시를 탈 수 있습니다. 터미널·Git·통합 프로시의 HTTP(S) 설정을 로컬 Clash의 mixed(혼합) 포트 또는 시스템 프록시에 맞추고, 앱이 무시하면 TUN 또는 시스템 프록시 활성 상태를 명시적으로 맞춥니다.

원격 에이전트·서버에서 OpenRouter만 별도 허용해야 한다면 회사 네트워크 정책과 분할 터널 범위를 먼저 확인하세요—Clash는 경로 선택 도구일 뿐 이용 약관·데이터 처리 규칙은 사용자 책임입니다.

FAQ

어떤 모델 이름을 고르든 같은데요

OpenRouter 종단 회선부터 점검하세요. 그다음에야 업스트림 공급자별 장애를 추적하는 것이 순서입니다.

규칙을 올렸는데도 동일 증상

해당 요청이 실제 매칭한 호스트 이름이 무엇인지 로그의 SNI·도메인 열에서 복사해 리스트를 보완합니다. 브라우저 전용 차단 플러그인 도 없는 상태에서 같은 경로만 재현하세요.

스트리밍 응답만 자꾸 끊김

TCP 유지 시간·중간 장비 TTL·무선 환경의 재연결 패턴까지 의심하고, 같은 노드를 고정한 채 짧은 응답과 긴 스트림을 교차 테스트합니다.

실무 체크리스트

통합 입구부터 안정히 잡기

OpenRouter처럼 하나의 API로 많은 선택지를 주는 레이어는 2026년에도 개발 시간을 줄여 주지만, 네트워크에서는 “한 줄짜리 URL”이라도 회선 변수는 그대로입니다. 분류 규칙과 DNS만 맞춰도 “게이트웨이가 전체적으로 끊긴다”는 인상 대부분이 좁아집니다.

Clash를 무료로 내려받아 분류 라우팅과 로그 검증부터 시작해 보세요