Codex 앱 접속 오류에서 먼저 구분할 증상
OpenAI Codex 앱을 실행했는데 로그인 화면이 반복되거나, 작업 목록은 열리지만 코딩 작업을 시작할 때 연결이 끊기거나, 응답이 오래 기다린 뒤 실패한다면 앱 자체의 문제라고 단정하기 전에 네트워크 경로부터 나눠 확인하는 편이 좋습니다. Clash 프록시를 사용 중이라면 특히 앱이 시스템 프록시를 따르는지, 요청이 Clash 규칙에 매칭되는지, 선택한 노드가 OpenAI 서비스와 안정적으로 통신하는지를 차례로 살펴봐야 합니다.
오류 형태에 따라 원인 후보도 달라집니다. 로그인 창이 뜨지 않거나 인증이 계속 반복되면 브라우저 인증과 앱 사이의 리디렉션, 인증 도메인 접근을 점검합니다. 로그인은 됐지만 작업 요청에서 시간 초과가 나면 API 연결, DNS 응답, 노드의 지연이나 연결 안정성을 살펴봅니다. 401이나 403처럼 HTTP 상태와 안내 문구가 명확하다면 프록시만 바꾸기보다 계정 권한, 조직 정책, 요금제 또는 서비스 측 제한도 확인해야 합니다. 프록시 설정은 계정 권한 오류를 해결하지 않습니다.
이 글은 Clash Verge Rev와 Mihomo 계열 클라이언트를 기준으로 설명하지만, 다른 Clash 클라이언트에서도 점검 순서는 거의 같습니다. 메뉴 이름은 버전과 운영체제에 따라 다를 수 있으므로, 특정 버튼 위치보다 프로필 활성화 → 연결 경로 확인 → 규칙 확인 → DNS와 노드 비교라는 흐름에 맞춰 진행하세요. 먼저 브라우저에서 OpenAI 계정 페이지가 열리는지 확인하면 앱 문제와 전체 네트워크 문제를 구분하는 데 도움이 됩니다.
1단계: 프로필과 프록시 모드를 확인하기
Clash를 열고 현재 사용할 프로필이 선택되어 있으며 코어가 정상 실행 중인지 확인합니다. 구독 프로필을 새로 가져온 직후라면 업데이트가 완료됐는지, 파싱 오류나 규칙 프로바이더 오류가 표시되지 않는지도 살펴보세요. 프로필이 목록에 보인다는 사실만으로 실제 트래픽에 적용됐다고 볼 수는 없습니다. 활성 프로필과 실행 중인 코어가 서로 다른 상태라면 설정 화면은 정상처럼 보여도 앱 연결은 기본 네트워크로 나갈 수 있습니다.
처음 원인을 좁힐 때는 규칙 모드에서 시작하는 것이 좋습니다. 규칙 모드는 호스트별로 프록시 그룹이나 DIRECT 경로를 선택하므로, Codex 앱 요청이 어디로 분기됐는지 연결 기록에서 확인할 수 있습니다. 글로벌 모드는 전체 트래픽을 한 프록시 경로로 보내는 비교 테스트에는 쓸 수 있지만, 다른 웹사이트나 사내 서비스까지 같은 경로로 바뀌어 별도의 문제를 만들 수 있습니다. 잠깐 테스트한 뒤에는 원래 모드로 되돌리고, 모든 트래픽을 무조건 프록시로 고정하는 방식은 상시 해결책으로 삼지 마세요.
앱에서 사용하는 연결 방식도 확인합니다. 일부 데스크톱 앱은 운영체제의 시스템 프록시 설정을 따르지만, 앱 내부 네트워크 구성이나 업데이트에 따라 동작이 달라질 수 있습니다. Clash에서 시스템 프록시를 켠 다음 브라우저만 정상인지, Codex 앱도 함께 연결되는지 따로 비교하세요. 시스템 프록시가 켜져 있어도 앱이 해당 설정을 읽지 않는 경우에는 TUN 모드나 앱이 지원하는 프록시 설정을 검토할 수 있습니다. TUN을 켤 때는 권한 승인과 다른 VPN·보안 프로그램과의 충돌 여부를 확인하고, 여러 가상 네트워크 도구를 동시에 켠 상태에서 원인을 판단하지 않는 편이 안전합니다.
- 프로필이 비활성이면 먼저 올바른 프로필을 선택하고 코어를 재시작합니다.
- 브라우저와 앱이 모두 실패하면 전체 연결, 노드 상태, DNS를 먼저 확인합니다.
- 브라우저는 되지만 Codex 앱만 실패하면 앱의 프록시 인식 여부와 앱 실행 환경을 따로 점검합니다.
- 특정 모드에서만 성공하면 그 결과를 기록하고 규칙 매칭을 확인한 뒤, 불필요한 전체 프록시 적용은 피합니다.
2단계: Codex 요청이 어떤 규칙을 타는지 확인하기
Clash의 연결 기록을 열어 Codex 앱에서 로그인하거나 작업을 실행하는 순간 새로 생기는 연결을 확인합니다. 호스트 이름, 연결 결과, 적용된 규칙, 선택된 프록시 그룹을 함께 살펴보면 요청이 DIRECT로 나갔는지, 프록시 그룹을 탔는지, 아니면 차단 규칙에 걸렸는지 구분할 수 있습니다. 로그를 보기 전에 브라우저 탭과 다른 앱을 잠시 닫고 Codex에서 한 가지 동작만 재현하면, 관련 연결을 찾기가 한결 쉽습니다.
OpenAI 제품은 로그인, 웹 화면, API 요청 등 기능에 따라 서로 다른 호스트를 사용할 수 있고, 앱 버전이나 배포 환경에 따라 연결 대상도 달라질 수 있습니다. 그러므로 인터넷에서 발견한 도메인 목록을 무조건 통째로 규칙에 넣기보다 실제 실패 시각의 Clash 로그에 나타난 호스트를 기준으로 판단하세요. 흔히 확인 대상이 되는 이름으로는 api.openai.com, auth.openai.com, chatgpt.com 등이 있지만, 이것이 모든 Codex 앱 요청의 전체 목록이라는 뜻은 아닙니다. 보이지 않는 호스트나 다른 인증 경로가 있을 수 있습니다.
관련 호스트가 DIRECT로 빠지고 해당 네트워크에서 접속이 막힌다면, 개인 규칙 오버라이드 기능이 있는 경우 그 호스트에 한해 적절한 프록시 그룹으로 보내는 방법을 검토할 수 있습니다. 반대로 이미 프록시 그룹을 타는데 연결이 계속 실패한다면 규칙을 더 추가하기보다 노드 상태와 인증 응답을 확인하세요. 같은 도메인에 여러 규칙이 적용될 수 있으므로, YAML을 직접 수정할 때는 위에서부터 먼저 매칭되는 규칙이 무엇인지 확인해야 합니다. 구독에서 내려받은 원본 파일을 직접 고치면 다음 업데이트 때 변경 사항이 사라질 수 있으니 클라이언트의 오버라이드나 로컬 보조 규칙을 사용하고, 인증 토큰이 들어간 설정 파일은 공개 저장소나 채팅에 올리지 마세요.
3단계: DNS와 노드 상태를 따로 시험하기
호스트 규칙이 맞아 보여도 DNS가 실패하면 연결은 시작되지 않습니다. Clash의 DNS 설정을 바꾼 뒤에는 코어를 재시작하고 같은 동작을 다시 재현해 결과를 비교하세요. 운영체제에 남은 DNS 캐시나 다른 VPN의 DNS 처리 방식이 영향을 줄 수도 있으므로, 한 번에 여러 옵션을 바꾸기보다 변경 전 설정과 시간을 메모해 두는 것이 좋습니다. 문제가 해결되면 마지막으로 바꾼 항목이 원인이었는지 되돌려 확인할 수 있습니다.
노드는 지연 시간 숫자만으로 고르지 말고, 실제 앱 연결 결과와 함께 비교해야 합니다. 지연이 낮게 표시되는 노드라도 장시간 연결에서 끊기거나 특정 서비스와의 TLS 연결이 불안정할 수 있습니다. 같은 규칙과 프로필을 유지한 상태에서 노드만 하나씩 바꾸고, Codex 로그인과 짧은 작업 요청을 각각 시험합니다. 여러 노드를 한꺼번에 변경하거나 글로벌 모드와 DNS 설정까지 동시에 바꾸면 무엇이 효과가 있었는지 알기 어렵습니다.
실패 시각을 기준으로 Codex 앱의 오류 메시지와 Clash 연결 기록을 맞춰 보는 것도 중요합니다. 해당 순간에 관련 연결이 전혀 없다면 앱이 시스템 프록시를 따르지 않거나, 요청 전에 인증·앱 내부 단계에서 막혔을 가능성을 살펴볼 수 있습니다. 연결이 기록되지만 DIRECT로 나갔다면 규칙 분기, 프록시 그룹으로 갔지만 시간 초과가 났다면 노드나 업스트림 경로를 우선 확인합니다. DNS 오류가 표시된다면 호스트 규칙만 바꾸는 것으로 해결되지 않을 수 있습니다.
- DNS 오류 또는 호스트를 찾을 수 없음: DNS 응답, Clash DNS 사용 여부, 운영체제의 DNS 캐시를 확인합니다.
- 연결은 기록되지만 시간 초과: 선택된 그룹과 노드를 바꿔 같은 요청을 비교합니다.
- 연결 기록에 요청이 없음: 앱의 시스템 프록시 지원, TUN 상태, 앱 재시작 여부를 확인합니다.
- 401·403 등 응답을 받음: 네트워크 연결은 성립했을 수 있으므로 계정과 서비스 권한도 확인합니다.
4단계: 앱 재시작과 네트워크 환경을 정리하기
프록시나 TUN 설정을 바꾼 뒤에는 Codex 앱을 완전히 종료하고 다시 실행합니다. 창만 닫는 동작이 백그라운드 프로세스를 종료하지 않는 앱도 있으므로, 메뉴에서 종료한 뒤 작업 관리자나 시스템 모니터에서 관련 프로세스가 남아 있는지 확인하세요. 기존 연결이 살아 있는 동안에는 새 시스템 프록시 설정이 바로 반영되지 않을 수 있습니다. 단, 로그인 세션이 꼬였다고 판단해 앱 데이터나 인증 정보를 무작정 삭제하지 말고, 먼저 로그아웃·로그인이나 공식 앱 복구 절차를 확인합니다.
터미널이나 IDE에서 Codex 관련 도구도 함께 사용한다면, 데스크톱 앱과 셸이 서로 다른 프록시 설정을 가질 수 있다는 점을 기억하세요. 터미널에서 사용하는 환경 변수는 앱의 시스템 프록시 설정과 별개로 적용될 수 있습니다. 예를 들어 HTTPS_PROXY 또는 ALL_PROXY가 오래된 포트를 가리키거나, NO_PROXY에 예상하지 못한 호스트가 들어 있으면 CLI만 다른 경로를 탈 수 있습니다. 환경 변수를 바꾼 뒤에는 새 터미널과 IDE를 열어 테스트하고, 자격 증명이나 구독 정보가 포함된 프록시 주소를 기록에 남기지 마세요.
회사·학교 네트워크에서는 프록시 사용 자체가 제한되거나, 인증서 검사와 보안 정책이 TLS 연결에 영향을 줄 수 있습니다. 이런 경우 정책을 우회하려 하기보다 네트워크 관리자에게 허용된 연결 방법을 확인하는 것이 우선입니다. 공용 Wi-Fi와 모바일 핫스팟처럼 다른 네트워크에서 한 번 비교하면 공유기나 기관 네트워크 문제인지 좁힐 수 있지만, 계정 보안과 조직 규정을 지키는 범위에서만 시험하세요. Clash 로그를 공유해야 한다면 노드 주소, 구독 URL, 토큰, 개인 식별 정보가 포함되지 않도록 먼저 가립니다.
자주 묻는 질문
브라우저는 되는데 Codex 앱만 연결되지 않는 이유는 무엇인가요?
브라우저가 운영체제 시스템 프록시를 따르더라도 Codex 앱은 같은 설정을 사용하지 않을 수 있습니다. Clash 연결 기록에 앱 실행 시점의 관련 요청이 있는지 확인하고, 요청이 없다면 앱의 프록시 인식 방식과 TUN 사용 여부를 점검하세요. 요청은 있지만 DIRECT로 나간다면 규칙을, 프록시 경로에서 시간 초과가 난다면 노드를 비교합니다.
글로벌 모드로 바꾸면 해결되는데 계속 사용해도 되나요?
글로벌 모드는 규칙 누락 여부를 비교하는 임시 테스트에 유용할 수 있지만, 전체 트래픽이 같은 경로를 타면서 지역 서비스나 내부 사이트까지 영향을 받을 수 있습니다. 글로벌 모드에서만 연결된다면 로그를 확인해 필요한 호스트의 규칙을 좁혀 조정하고, 평소에는 자신의 사용 환경에 맞는 모드로 되돌리는 편이 관리하기 쉽습니다.
어떤 OpenAI 도메인을 프록시 규칙에 추가해야 하나요?
Codex 앱의 버전과 기능에 따라 요청 호스트가 달라질 수 있으므로 고정 목록만 복사하기보다 실패를 재현한 시각의 Clash 로그를 기준으로 판단하세요. 실제로 DIRECT로 분기된 관련 호스트만 필요한 범위에서 조정하고, 너무 넓은 도메인 키워드 규칙은 다른 서비스의 트래픽까지 바꿀 수 있으니 피합니다.
401이나 403 오류도 노드를 바꾸면 해결되나요?
항상 그렇지는 않습니다. 401은 인증 정보나 세션 문제, 403은 계정·조직 정책 또는 접근 제한과 관련될 수 있으며, 서비스가 응답을 반환했다면 네트워크 연결 자체는 이미 성립했을 가능성이 있습니다. 오류 문구와 계정 상태를 먼저 확인하고, 연결 시간 초과나 DNS 오류와 구분해 대응하세요.
일부 앱은 시스템 프록시 설정을 잘 따르지 않거나 연결 상태를 자세히 보여 주지 않아 원인 파악이 번거롭고, 규칙을 직접 관리하기 어려운 클라이언트는 앱별 분기 확인에 시간이 걸릴 수 있습니다. 반면 Clash에서는 연결 기록으로 실제 호스트와 분기 결과를 살피고, 프로필·노드·DNS를 나눠 점검할 수 있어 Codex 앱 접속 문제를 단계적으로 좁히기 좋습니다. Windows나 macOS에서 Clash 클라이언트를 시작하려면 운영체제에 맞는 다운로드 정보를 확인하세요.