npm install만 멈추고 OpenAI API 호출은 될 때는?

메타데이터 요청 호스트와 tarball CDN이 서로 다른 정책 그룹으로 나가면 중간에 끊긴 것처럼 보입니다. npm config get registry의 실제 호스트와 로그 도메인을 맞춥니다.

Azure OpenAI 엔드포인트를 쓰면 규칙은 어떻게 하나요?

리소스 URL의 호스트(예: 리전별 openai.azure.com 계열)를 로그에서 확정해 DOMAIN 규칙으로 추가합니다. 공용 api.openai.com 목록만으로는 부족할 수 있습니다.

Codex CLI·OpenAI·npm

1. 웹 ChatGPT·Gemini CLI 글과 무엇이 다른가

이 사이트의 ChatGPT 라우팅·Workspace Agents류 글은 주로 브라우저·앱 셸과 openai.com·chatgpt.com 계열을 다룹니다. Gemini CLI 글은 Google AI·npm 조합에 초점을 맞추고요. Codex CLI는 같은 「터미널에서 AI + 패키지 매니저」 복합 시나리오에 가깝지만, 종단은 OpenAI API와 인증 흐름이 중심이라 호스트 세트가 Google과 일치하지 않습니다. Claude Code 글의 Anthropic 축을 그대로 복사해 붙이면 api.anthropic.com만 맞고 OpenAI 측은 빠지기 쉽습니다. 항상 자신의 mihomo 연결 로그에 찍힌 이름부터 좁혀 가야 합니다.

또한 브라우저는 QUIC·탭 단위 격리 덕분에 패킷 경로가 터미널 Node 프로세스와 다르게 보일 수 있습니다. Codex CLI는 긴 시간 HTTPS 연결을 유지하고 옆 스레드에서는 npx가 registry 메타와 tarball을 순차로 열기 때문에, 검색 의도는 「브라우저만 열면 되는가」보다 「같은 터미널에서 API와 패키지 다운로드가 동시에 안정적인가」에 더 가깝습니다.

2. 터미널에서 보이는 단계별 증상

사용자는 흔히 타임아웃 한 단어로 검색하지만, 실제로는 TLS 핸드셰이크 초반에서 끊기는 경우와, npm tarball 스트림 중간에서 대역 없이 대기하는 경우가 다릅니다. 전자는 종종 노드 회선·SNI·중간 장비와 연관되고, 후자는 레지스트리와 tarball 호스트가 서로 다른 정책 그룹으로 나가거나 npm 쪽 중복 프록시 설정이 겹친 경우가 많습니다.

DNS만 느리게 보이는 경우도 있습니다. 시스템이 IPv6를 우선 시도했다가 특정 구간에서 막히면, 규칙만 손봐서는 해결되지 않을 수 있습니다. 증상을 한 줄로 단정하기보다 로그에 찍힌 목적 호스트명과 아웃바운드 이름을 먼저 확정하는 편이 빠릅니다. OPENAI_API_KEY 누락이나 요금·한도 오류는 네트워크가 아니라 계정 응답으로 나오는 경우가 분명히 구분되므로, HTTP 상태 코드·메시지도 함께 확인하세요.

메모

Codex CLI는 OpenAI API와 npm을 동시에 밟으므로 단일 GEOIP 규칙으로는 한쪽만 들어맞는 체감이 생기기 쉽습니다. API·레지스트리·tarball을 구간별로 규칙 조각을 쌓는 편이 낫습니다.

3. 규칙 후보: OpenAI·npm·CDN

아래 목록은 시작점입니다. 제품 업데이트와 리전 정책에 따라 호스트가 늘거나 바뀔 수 있으므로, 실제 트레이스에서 보이는 이름을 우선합니다. 일반적으로 api.openai.com, DOMAIN-SUFFIX,openai.com, 브랜드·로그인에 쓰이는 chatgpt.com, 정적 자원·사용자 첨부에 자주 등장하는 oaistatic.com·oaiusercontent.com 등이 한 세션에 함께 붙습니다. Sora·영상 글에서 다룬 접미 규칙 일부가 OpenAI 웹 전반과 겹칠 수 있으나, Codex가 반드시 모든 CDN을 밟는 것은 아니므로 과도하게 넓히지 말고 로그로 확인하세요.

조직에서 Azure OpenAI 엔드포인트를 쓰는 경우, 호스트 이름이 공용 api.openai.com과 완전히 다릅니다. 클라이언트가 설정한 base URL을 기준으로 DOMAIN 규칙을 추가해야 합니다. npm 측에서는 최소 registry.npmjs.org와 npmjs.org 패밀리를 잡고, 사내 미러(registry.npmmirror.com 등)를 쓰면 그 호스트를 별도 규칙으로 두는 것이 오탐을 줄입니다. Windows npm 글의 npm config list 절차와 연계하면 좋습니다.

OpenAI API·앱 셸

인증·리다이렉트·API가 서로 다른 서브도메인을 쓸 수 있습니다. 한 그룹에 묶더라도 로그에서 순서를 재확인하세요.

npm registry

npm config get registry가 기본이 아니면, 그 URL의 호스트를 규칙 최우선에 넣습니다.

4. 환경 변수·npm 레지스트리 정렬

macOS·Linux·WSL에서는 HTTP_PROXY·HTTPS_PROXY를 Clash mixed-port에 맞추는 방식이 널리 쓰입니다. PowerShell·네이티브 윈도에서는 회사 SSL 검사·별도 네트워크 스택이 끼어들 수 있습니다. 과거에 npm config set proxy를 수동으로 넣었다가 잊은 경우, CLI만 이중으로 프록시를 타기도 하니 빈 셸에서 npm config list로 대조해 보세요.

TUN 모드가 켜져 있으면 환경 변수 의존도는 줄지만, 예외 앱·루프백 규칙은 여전히 필요할 수 있습니다. MCP·npm·GitHub 글에서 말한 것처럼, 대용량 의존성 트리를 당길 때 메타 호스트와 tarball 호스트가 갈라지면 중간에 멈춘 것처럼 보입니다. Docker·WSL을 함께 쓰면 DNS·프록시 이중 구조를 한 번 더 점검하는 것이 안전합니다.

5. mihomo rules 스니펫과 우선순위

예시 정책 그룹 이름을 🔷 Codex-Dev-OpenAI-Npm으로 두었습니다. 구독에 맞게 바꾸고, MATCH·넓은 GEOIP보다 위쪽에 두세요. 세부 순서는 고급 라우팅 문서와 함께 보는 것을 권합니다.

rules:
  # Codex CLI-ish: openai + npm; widen from your live connection logs
  - DOMAIN,api.openai.com,🔷 Codex-Dev-OpenAI-Npm
  - DOMAIN-SUFFIX,openai.com,🔷 Codex-Dev-OpenAI-Npm
  - DOMAIN-SUFFIX,chatgpt.com,🔷 Codex-Dev-OpenAI-Npm
  - DOMAIN-SUFFIX,oaistatic.com,🔷 Codex-Dev-OpenAI-Npm
  - DOMAIN-SUFFIX,oaiusercontent.com,🔷 Codex-Dev-OpenAI-Npm
  - DOMAIN-SUFFIX,registry.npmjs.org,🔷 Codex-Dev-OpenAI-Npm
  - DOMAIN-SUFFIX,npmjs.org,🔷 Codex-Dev-OpenAI-Npm
  # Add Azure OpenAI / org-specific hosts from your base URL if needed

  # ... LAN / direct paths, then GEOIP/MATCH ...
  - GEOIP,PRIVATE,DIRECT
  - MATCH,🔰 Proxy

DOMAIN-SUFFIX,openai.com은 범위가 넓습니다. 불필요한 트래픽까지 같은 그룹으로 끌고 가기 싫다면 로그에서 자주 나오는 FQDN을 먼저 분리하고, 넓은 줄은 검증 뒤에만 유지하세요. 스니펫 복사는 항상 「확정된 호스트부터」가 안전합니다.

6. DNS·Fake-IP·보안 DNS 충돌 줄이기

Clash Meta의 fake-ip는 규칙 매칭을 단순하게 만들지만, 터미널 실행 파일이 로컬 스텁 리졸버와 직접 말하면 코어 밖에서 먼저 응답을 받을 수 있습니다. fake-ip와 redir-host 글로 모드 선택을 재점검하세요. OpenAI·npm 접미사마다 nameserver-policy를 나누는 스케치는 아래와 같습니다. 실제 업스트림은 조직 정책에 맞게 고르세요.

# Sketch — pick resolvers that match your audit / filter policy
dns:
  nameserver-policy:
    "+.openai.com":
      - https://dns.google/dns-query
    "+.npmjs.org":
      - tls://dns.quad9.net

브라우저 보안 DNS와 기업 에이전트가 동시에 켜져 있으면 CLI만 지연처럼 느껴질 수 있습니다. 윈도우 보안 DNS 가이드를 참고해 실험 창에서만 비교해 보는 것도 방법입니다.

참고: DNS 서버 주소는 법규·필터 정책에 맞게 선택해야 합니다. 예시는 형식 안내이며 그대로 하드코딩할 목록이 아닙니다.

7. 정책 그룹과 장시간 API 세션

Codex CLI처럼 스트리밍 응답이 긴 세션은 짧은 주기의 url-test가 노드를 자주 바꿀 때 재연결 비용이 커질 수 있습니다. 전용 그룹 안에서는 지연 자동 전환보다 fallback·수동 선택을 함께 검토합니다. 패턴은 지연 테스트·fallback 글을 참고하세요.

반면 npm은 작은 HTTPS 요청이 연속으로 터집니다. API와 같은 노드를 공유하면 한쪽 회선 문제가 다른 쪽 체감까지 끌고 올 수 있어, 트래픽 성격이 크게 다르면 그룹을 나누는 것도 선택지입니다. 다만 그룹이 많아지면 유지 비용이 커지므로, 로그에서 병목 호스트를 본 뒤 결정하는 편이 좋습니다.

8. 로그 기반 실측 체크리스트

첫째, 문제가 나는 서브커맨드를 동일 인자로 재현하고 mihomo 로그에서 실패 줄의 도메인과 아웃바운드가 기대한 정책 그룹인지 확인합니다. 둘째, Proxies 화면에서 그 그룹이 실제로 어떤 노드를 가리키는지 스냅샷을 남깁니다. 셋째, 같은 셸에서 env | grep -i proxy류로 프록시 변수만 바꿔 A/B 비교합니다. 넷째, DNS 모드·TUN on/off·IPv6 on/off를 한 번씩만 바꿔 증상이 따라오는지 봅니다. API 자격과 한도는 HTTP 응답으로 구분해 네트워크 이슈와 섞이지 않게 합니다.

TLS에서 멈출 때

SNI·중간 검사 장비를 의심하고, 동일 호스트명을 openssl s_client 등으로 재현해 봅니다.

다운로드 중간 멈춤

tarball 호스트가 레지스트리와 다르면 메타 규칙만으로는 부족합니다. tarball 줄까지 로그에 나오는지 확인합니다.

전체적인 분기 개념을 다시 보고 싶다면 Clash 개요 페이지로 흐름을 정리할 수 있습니다.

9. 자주 묻는 질문

브라우저 ChatGPT는 되는데 Codex CLI만 타임아웃될 때는?

브라우저는 시스템 프록시·QUIC 경로가 다르고, 터미널은 HTTP_PROXY 미설정·레지스트리 직결·IPv6 우선 등으로 같은 정책 그룹을 타지 않을 수 있습니다. 터미널 환경 변수와 mihomo 연결 로그를 함께 보세요.

npm install만 멈추고 OpenAI API는 될 때는?

메타데이터 요청과 tarball CDN이 서로 다른 정책 그룹으로 나가면 패키지 설치 중간에서 끊긴 것처럼 보입니다. npm config get registry의 실제 호스트와 로그 도메인을 맞춥니다.

Fake-IP를 쓰면 왜 규칙이 안 먹는 것처럼 보이나요?

앱이나 OS가 코어 바깥에서 먼저 DNS를 해석하면 Clash 규칙과 실제 접속 목적지가 어긋날 수 있습니다. redir-host·nameserver-policy·브라우저 보안 DNS를 함께 점검하세요.

Azure OpenAI만 쓰는데도 같은 스니펫이 되나요?

리전 엔드포인트 호스트가 다르면 별도 DOMAIN 행이 필요합니다. 클라이언트에 설정된 base URL을 기준으로 로그에서 이름을 확정하세요.

일반적인 VPN 클라이언트가 「전체 트래픽을 한 출구로만 밀어 넣는」 데 초점을 두는 경우가 많다면, Clash·mihomo 계열은 호스트 단위로 정책을 쌓을 수 있어 Codex CLI처럼 API·인증·npm registry가 한 세션에 섞이는 개발 환경에서 유리합니다. GUI에서 도메인 규칙과 로그·DNS 토글을 한 화면에서 다루기 어렵거나, 단일 터널만 제공하는 타사 앱은 세밀한 분기 조정에 시간이 더 드는 경우가 많습니다. 규칙 순서·패널·DNS를 묶어 다룰 수 있는 클라이언트라면 TLS·패키지 단계로 나뉘어 보이던 증상도 같은 테이블에서 정리하기 쉽습니다.

→ Clash를 무료로 받아 최신 클라이언트와 함께 OpenAI·npm 두 축을 동시에 점검하고, 명령줄 타임아웃을 줄이는 규칙 세트를 천천히 다듬어 보세요.