OpenAI Codex를 Clash로 쓰는 법｜접속 설정과 안정화 팁

OpenAI Codex를 활용해 AI 코딩을 시작하려는 개발자가 늘고 있습니다. 하지만 로그인 화면이 반복해서 갱신되거나, 코드 생성 요청이 오래 멈추거나, 저장소와 패키지 레지스트리에 접근하지 못하면 작업 흐름이 쉽게 끊깁니다. 이런 문제는 Codex 자체의 오류뿐 아니라 DNS 응답, 노드 품질, 라우팅 규칙, 시스템 프록시 적용 범위가 서로 맞지 않아 발생하기도 합니다. 이 글에서는 Clash 또는 Mihomo에서 구독을 등록하고, Codex에 필요한 트래픽만 안정적으로 프록시하며, 문제가 생겼을 때 원인을 단계적으로 찾는 방법을 설명합니다.

Codex와 Clash 구성 전 확인할 사항

먼저 사용 중인 Codex 환경을 구분해야 합니다. 터미널에서 실행하는 Codex CLI, 에디터 확장 기능, 브라우저 기반 로그인 페이지는 서로 다른 프로세스와 네트워크 경로를 사용할 수 있습니다. Clash Verge나 Clash Verge Rev에서 시스템 프록시를 켰더라도 터미널 프로세스가 그 설정을 자동으로 따르지 않을 수 있으며, 반대로 TUN 모드를 켜면 시스템 프록시를 인식하지 않는 프로그램까지 가상 네트워크 인터페이스를 통해 처리할 수 있습니다.

설정을 시작하기 전에 다음 항목을 확인하세요.

• Clash 클라이언트가 실행 중이고 현재 사용 중인 코어가 설정 파일 형식을 지원하는지 확인합니다. 최신 기능과 TUN, DNS 제어가 필요하다면 Mihomo 기반 클라이언트가 편리합니다.
• 구독 URL이 정상적으로 열리고, 구독에서 내려받은 노드의 서버 주소와 인증 정보가 만료되지 않았는지 확인합니다.
• 운영체제의 날짜와 시간이 정확한지 확인합니다. TLS 인증서 검증과 로그인 토큰 처리에서 시간 오차가 문제를 만들 수 있습니다.
• 이미 실행 중인 VPN, 다른 프록시 앱, 기업 보안 프로그램이 Clash의 포트나 TUN 인터페이스와 충돌하지 않는지 확인합니다.
• Codex 계정과 API 사용 권한을 정상적인 공식 절차로 준비합니다. Clash는 네트워크 경로를 조정하는 도구이며 계정 제한이나 서비스 정책을 우회하는 도구가 아닙니다.

Clash에 구독 등록하고 노드 준비하기

Clash Verge 계열 클라이언트에서는 일반적으로 프로필 화면에서 구독 URL을 추가한 뒤 프로필을 업데이트합니다. 클라이언트마다 메뉴 이름은 조금 다르지만 흐름은 비슷합니다. 새 프로필 또는 구독 추가를 선택하고 URL을 입력한 다음, 내려받은 프로필을 활성화하세요. 로컬 YAML 파일을 직접 관리한다면 파일을 가져온 후 현재 프로필로 선택하면 됩니다.

1. Clash 클라이언트를 열고 프로필 또는 Profiles 화면으로 이동합니다.
2. 구독 URL을 추가하고 이름을 알아보기 쉽게 지정합니다. 예를 들어 codex-work처럼 용도를 표시하면 여러 프로필을 관리하기 쉽습니다.
3. 업데이트가 끝난 뒤 프록시 또는 Proxies 화면에서 노드 목록이 표시되는지 확인합니다.
4. 노드 그룹에서 몇 개의 후보를 골라 지연 시간과 연결 성공 여부를 비교합니다. 단순히 핑이 가장 낮은 노드보다 HTTPS 요청이 실제로 성공하는 노드가 더 중요합니다.
5. 정상 노드 하나를 수동으로 선택한 뒤 브라우저에서 로그인 페이지와 일반 HTTPS 사이트를 각각 확인합니다.

구독에 포함된 노드가 많으면 처음부터 모든 노드를 자동 테스트할 필요는 없습니다. 지역, 전송 방식, 최근 응답 여부를 기준으로 3~5개만 남겨 테스트하면 결과를 해석하기 쉽습니다. url-test 그룹을 사용하면 일정한 간격으로 테스트 URL을 요청해 상대적으로 빠른 노드를 선택할 수 있고, fallback 그룹을 사용하면 기본 노드가 실패했을 때 백업 노드로 전환할 수 있습니다.

proxy-groups:
  - name: Codex-Auto
    type: url-test
    proxies:
      - node-us-01
      - node-jp-01
      - node-sg-01
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

Codex 트래픽을 안정적으로 라우팅하기

모든 트래픽을 무조건 프록시로 보내는 방식은 간단하지만 항상 좋은 선택은 아닙니다. 로컬 개발 서버, 사내 저장소, 패키지 미러처럼 직접 연결이 더 빠르고 정책상 로컬 경로가 필요한 대상까지 프록시하면 오히려 문제가 늘어납니다. 반대로 로그인과 API 요청을 직접 연결하면 DNS 오염, 인증서 연결 실패, 긴 대기 시간이 발생할 수 있습니다.

실전에서는 도메인 기반 규칙을 먼저 배치하고, 마지막에 기본 규칙을 두는 방식이 관리하기 좋습니다. 정확한 도메인 목록은 사용 중인 Codex 클라이언트와 서비스 환경에 따라 달라질 수 있으므로, 특정 주소를 무조건 고정하기보다 연결 로그에서 실제 목적지를 확인해 점진적으로 추가하세요.

rules:
  # 실제 환경에서 확인한 인증 및 API 도메인을 필요한 만큼 추가
  - DOMAIN-SUFFIX,openai.com,Codex-Auto
  - DOMAIN-SUFFIX,chatgpt.com,Codex-Auto
  - DOMAIN-SUFFIX,auth.openai.com,Codex-Auto
  - DOMAIN-SUFFIX,github.com,Codex-Auto
  # 로컬 개발 및 사설 네트워크는 직접 연결
  - DOMAIN-SUFFIX,local,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,Codex-Auto

위 예제의 도메인은 모든 환경에서 동일하게 필요한 고정 목록이 아닙니다. 서비스가 사용하는 실제 호스트는 클라이언트 버전, 로그인 방식, 지역, 네트워크 환경에 따라 바뀔 수 있습니다. 특정 도메인을 추가했는데도 문제가 해결되지 않는다면 Clash의 연결 목록에서 실패한 요청을 찾아 목적지와 적용된 규칙을 확인하세요. 규칙이 너무 넓어지면 일반 웹 트래픽까지 같은 노드를 사용하게 되므로, 가능한 한 DOMAIN-SUFFIX나 정확한 DOMAIN 규칙을 우선 사용합니다.

DNS와 TUN 모드 조정하기

Codex 로그인 실패의 원인이 노드가 아니라 DNS인 경우도 많습니다. 앱이 로컬 DNS에서 잘못된 주소를 받아 연결하면 Clash 규칙이 의도대로 적용되지 않을 수 있습니다. Mihomo에서는 fake-ip 모드가 도메인 기반 라우팅과 잘 결합됩니다. DNS 요청을 받은 뒤 임시 주소를 앱에 반환하고, Clash 내부에서 도메인과 임시 주소의 매핑을 유지하므로 실제 IP를 기다리기 전에 도메인 규칙을 적용할 수 있습니다.

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - 'localhost.ptlogin2.qq.com'

TUN 모드는 시스템 프록시를 인식하지 않는 터미널, 에디터, 백그라운드 프로세스까지 처리하는 데 유용합니다. 다만 운영체제 권한을 요구하거나 다른 VPN과 충돌할 수 있습니다. TUN을 켠 뒤 인터넷 전체가 끊긴다면 먼저 TUN을 끄고 시스템 프록시만으로 브라우저 연결을 테스트한 다음, 다시 TUN을 활성화해 범위를 좁혀 보세요. DNS를 변경한 뒤에는 기존 연결과 DNS 캐시가 남아 있을 수 있으므로 Clash를 재시작하고 터미널 및 에디터도 함께 다시 실행하는 것이 좋습니다.

터미널과 에디터에서 프록시 확인하기

브라우저가 정상적으로 열리는데 Codex CLI만 연결되지 않는다면 해당 프로세스가 시스템 프록시를 사용하지 않는 상황일 가능성이 큽니다. Clash의 혼합 포트가 7890이라고 가정하면 셸에서 임시 환경 변수를 설정해 요청 경로를 확인할 수 있습니다. 포트 번호는 클라이언트의 일반 설정 화면에서 실제 값을 확인해야 합니다.

# macOS / Linux
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=http://127.0.0.1:7890

# 연결 테스트 예시
curl -I https://api.openai.com

Windows PowerShell에서는 현재 세션에만 환경 변수를 적용할 수 있습니다.

$env:HTTP_PROXY = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"
$env:ALL_PROXY = "http://127.0.0.1:7890"
curl.exe -I https://api.openai.com

환경 변수만 설정해도 해결되지 않는 프로그램이 있습니다. 일부 도구는 자체 프록시 설정을 사용하고, 일부는 SOCKS5만 지원하거나 인증서 저장소를 별도로 관리합니다. 이때는 해당 도구의 공식 문서에서 프록시 옵션과 인증서 검증 방식을 확인하세요. TLS 검증을 무조건 끄는 방법은 빠른 테스트에는 보일 수 있지만 보안상 권장되지 않습니다.

연결 문제 진단과 성능 안정화

Codex가 멈출 때는 “인터넷이 안 된다”라고 판단하기보다 로그인, API 요청, Git 저장소, 패키지 다운로드 중 어느 단계가 실패했는지 나누어야 합니다. 각 단계의 목적지와 연결 시간을 Clash 대시보드에서 확인하면 문제를 훨씬 빨리 찾을 수 있습니다.

• 로그인 페이지가 열리지 않음: 브라우저가 시스템 프록시를 사용하는지 확인하고, DNS 응답과 인증 도메인의 규칙 매칭을 검사합니다.
• 로그인은 되지만 요청이 타임아웃됨: 현재 노드의 실제 HTTPS 연결 품질을 확인하고 다른 지역의 노드로 전환합니다.
• 코드 생성 중 자주 끊김: 지연 시간보다 패킷 손실과 장시간 연결 안정성이 중요합니다. 자동 전환 그룹의 테스트 간격이 너무 짧으면 세션이 중간에 바뀔 수 있습니다.
• GitHub 또는 패키지 설치만 실패: 해당 도메인이 직접 연결 규칙에 걸렸는지, 인증 프록시나 별도 환경 변수가 적용되는지 확인합니다.
• TUN 사용 후 로컬 서버가 열리지 않음: 127.0.0.1, 사설 IP 대역, 로컬 도메인을 DIRECT로 분리하고 가상 네트워크 설정을 점검합니다.

노드 선택에서는 단순한 핑 숫자보다 테스트 목적을 고려해야 합니다. 짧은 요청은 빠르지만 스트리밍 응답이나 긴 코드 생성 세션에서 끊기는 노드가 있을 수 있습니다. 따라서 브라우저 로그인, API 테스트, 저장소 접근을 모두 실행해 보고 가장 안정적인 노드를 기본값으로 선택하세요. 자동 그룹을 사용하더라도 tolerance를 적절히 설정해 작은 지연 시간 차이로 노드가 자주 바뀌지 않게 하는 것이 좋습니다.

마지막으로 정상적으로 작동하는 상태에서 프로필과 환경 변수를 백업하세요. 이후 클라이언트 업데이트나 구독 갱신으로 문제가 생겨도 이전 설정과 비교할 수 있습니다. OpenAI Codex는 빠른 요청 하나보다 지속적인 로그인, 안정적인 API 연결, 저장소 접근이 함께 유지될 때 생산성이 높아집니다. Clash에서는 필요한 도메인만 명확한 규칙으로 분기하고, 신뢰할 수 있는 노드를 선택하며, 연결 로그를 근거로 설정을 조정하는 것이 가장 안전한 운영 방법입니다.