Codex 앱만 연결되지 않을 때 먼저 구분할 것
브라우저에서 ChatGPT나 OpenAI 사이트가 열리는데 Codex 앱에서는 로그인, 작업 시작 또는 응답 수신이 실패한다면 같은 네트워크를 사용한다는 이유만으로 경로도 같다고 단정하기 어렵습니다. 데스크톱 앱은 앱 자체의 네트워크 처리 방식과 운영체제의 시스템 프록시 설정을 따를 수 있고, 브라우저는 별도의 프록시 확장 기능이나 자체 설정을 사용할 수 있습니다. 앱 버전, 운영체제, 설치 형태에 따라서도 동작이 달라질 수 있으므로 특정 호스트 이름을 미리 정해 규칙에 넣기보다 실제 연결 로그를 기준으로 확인하는 편이 안전합니다.
먼저 오류가 어느 단계에서 나타나는지 적어 둡니다. 앱이 실행되지만 로그인 화면이 비어 있는지, 인증은 끝났는데 작업 요청이 시간 초과되는지, 응답 생성 중 연결이 끊기는지에 따라 점검할 층이 다릅니다. 로그인 단계에서는 브라우저 인증 창과 앱으로 돌아오는 과정이 관련될 수 있고, 작업 단계에서는 API 연결이나 스트리밍이 별도로 실패할 수 있습니다. 브라우저에서 같은 계정으로 접속되는지 확인하되, 브라우저 성공만으로 Codex 앱의 프록시 경로까지 정상이라고 판단하지 마세요.
문제가 재현되는 순간 Clash의 연결 또는 Connections 화면을 열고 새로 생긴 연결을 확인합니다. 실패 시간에 맞춰 최근 항목을 살피고, 화면에서 제공하는 검색 기능이 있다면 OpenAI 관련 이름이나 앱 프로세스 이름으로 좁혀 봅니다. 표시되는 호스트와 정책 그룹, 선택된 노드, 연결 상태를 메모하면 규칙 문제와 노드 문제를 구별하기 쉬워집니다. 로그에 기록된 도메인은 앱 버전이나 기능에 따라 달라질 수 있으므로, 인터넷에서 찾은 목록을 그대로 복사해 적용하지 않는 것이 좋습니다.
DIRECT로 나가거나 예상과 다른 그룹에 들어간다면 규칙을 살펴보고, 올바른 그룹에 들어갔는데 연결만 실패한다면 노드와 DNS를 확인합니다.
시스템 프록시와 TUN 모드가 앱에 적용되는지 확인
Clash에서 시스템 프록시를 켜면 일반적으로 운영체제가 지원하는 프록시 설정을 참조하는 앱의 요청이 Clash의 혼합 포트 또는 HTTP 프록시 경로로 전달됩니다. 하지만 모든 데스크톱 앱이 시스템 프록시를 똑같이 따르는 것은 아닙니다. 앱이 별도의 네트워크 라이브러리를 사용하거나 프록시 환경 변수를 따로 요구한다면, 시스템 프록시 표시가 활성화되어 있어도 일부 연결이 로그에 나타나지 않을 수 있습니다. 따라서 우선 Clash 화면에서 시스템 프록시가 실제로 켜져 있는지 확인하고, Codex 앱을 완전히 종료한 뒤 다시 실행해 증상이 달라지는지 비교합니다.
TUN 모드는 앱이 시스템 프록시 설정을 따르지 않는 상황에서 IP 트래픽을 가로채는 대안이 될 수 있습니다. 다만 TUN을 켰다고 모든 연결이 자동으로 올바른 노드로 향하는 것은 아닙니다. 가상 네트워크 인터페이스 권한, 운영체제의 보안 확인, 다른 VPN이나 네트워크 필터와의 충돌, 라우팅 및 DNS 설정도 함께 영향을 줍니다. TUN을 처음 켜는 경우에는 관리자 권한 요청을 주의해서 확인하고, 회사나 학교 기기에서는 허용된 네트워크 정책을 우선 따르세요.
원인을 좁히려면 한 번에 설정 하나만 바꿉니다. 시스템 프록시를 켠 상태에서 재현한 로그를 저장한 다음, 필요할 때만 TUN을 시험하고 같은 작업을 다시 수행합니다. 두 방식을 동시에 바꾸거나 다른 VPN까지 함께 켜면 어느 경로가 결과를 바꿨는지 알기 어렵습니다. TUN을 끈 뒤에도 예전 프록시 설정이 남아 앱이 잘못된 포트를 바라보는 경우가 있으므로, 테스트가 끝난 뒤에는 원래 상태로 복구하고 브라우저와 다른 앱의 연결도 확인합니다.
앱이 명시적인 프록시 설정이나 환경 변수 입력을 제공한다면 Clash가 사용 중인 포트와 프로토콜을 먼저 확인한 뒤 해당 입력란과 대조합니다. 포트 번호를 임의로 추측하지 말고, 클라이언트의 설정 화면에서 실제 값을 확인하세요. 또한 SOCKS 프록시만 설정했는데 앱이 HTTP 프록시를 기대하거나 그 반대인 경우에는 연결이 실패할 수 있습니다. 설정을 수정했다면 앱을 다시 시작하고 새 로그 항목이 생성되는지 확인합니다. 화면 구성은 Clash Verge, Clash Verge Rev, Mihomo Party 등 클라이언트와 버전에 따라 달라질 수 있지만 확인할 핵심은 프록시 활성 상태, 포트, 코어 실행 상태입니다.
규칙과 연결 로그로 요청이 어느 경로를 타는지 확인
규칙 모드에서 중요한 것은 “OpenAI를 프록시로 보낸다”는 의도와 실제로 일치하는 규칙이 적용되는지입니다. Clash는 위에서부터 규칙을 검사하므로, 앞쪽의 넓은 도메인 또는 IP 규칙이 요청을 먼저 잡으면 뒤에 추가한 좁은 규칙은 실행되지 않을 수 있습니다. 먼저 로그에서 Codex 앱이 실제로 연결한 도메인과 해당 연결에 적용된 규칙을 확인하고, 그 결과가 원하는 정책 그룹인지 비교합니다. 규칙 목록만 읽고 추측하기보다 연결 로그의 매칭 결과를 기준으로 수정하세요.
관찰한 호스트를 분류할 때는 도메인 접미 규칙을 무리하게 넓히지 않습니다. 관련 없는 서비스까지 같은 그룹에 포함되면 개인정보나 업무 트래픽이 의도하지 않은 경로로 나갈 수 있습니다. 반대로 특정 IP를 고정하는 방식은 CDN 주소가 바뀌었을 때 쉽게 낡을 수 있습니다. 로그에 여러 호스트가 나타난다면 각 요청의 역할을 단정하지 말고, 앱을 실행할 때와 로그인할 때, 실제 작업을 보낼 때를 나누어 관찰합니다. 필요한 변경은 확인된 도메인에 한해 최소 범위로 적용하고, 변경 전 프로필을 백업해 두세요.
규칙 모드에서만 실패하고 전역 프록시 모드에서는 같은 요청이 성공한다면, 노드 자체보다 규칙의 순서나 매칭 조건을 먼저 의심할 수 있습니다. 반대로 전역 모드에서도 같은 요청이 실패한다면 노드 연결 상태, DNS 응답, 네트워크의 인증 포털 또는 앱의 프록시 지원 여부를 확인합니다. 전역 모드는 원인 분리를 위한 짧은 테스트로 사용하고, 진단이 끝난 뒤에는 필요한 정책으로 되돌리세요. 로그를 다른 사람과 공유할 때는 계정 식별 정보, 토큰, 내부 도메인처럼 민감한 항목을 가린 뒤 전달하는 것이 좋습니다.
규칙 매칭 순서와 정책 그룹을 더 자세히 점검하려면 규칙 라우팅 모범 사례를 참고하고, 연결이 지연되거나 TLS 오류가 반복되면 연결 로그와 TLS 타임아웃 점검을 함께 살펴보세요. 핵심은 규칙을 많이 추가하는 것이 아니라, 실패 시점의 실제 연결 한두 개가 어떤 정책을 통과했는지 확인하는 것입니다.
노드·DNS·인증 상태를 차례로 점검하고 원복하기
Codex 앱의 연결이 올바른 프록시 그룹에 도달하더라도 선택한 노드가 API 요청이나 장시간 스트리밍에 적합하지 않으면 로그인 후 응답이 멈추거나 작업 도중 끊길 수 있습니다. 먼저 Clash에서 해당 노드가 연결 가능한 상태인지 확인한 뒤, 다른 안정적인 노드를 하나 선택해 같은 작업을 재현합니다. 이때 여러 노드를 한꺼번에 바꾸지 말고 각 테스트의 시간, 선택한 노드, 오류 문구를 기록하세요. 짧은 지연 시간 테스트에 통과한 노드도 장시간 연결의 안정성을 보장하지는 않으므로 실제 앱 작업 결과를 함께 비교해야 합니다.
DNS 문제도 구분해서 살펴봅니다. 도메인 조회가 실패하거나 예상하지 않은 응답을 받으면 연결 로그에 요청 자체가 남지 않거나, 연결이 빠르게 실패하는 모습이 나타날 수 있습니다. Clash 코어의 DNS 설정을 최근에 변경했다면 이전 설정과 비교하고, 운영체제에 남은 다른 DNS 필터나 VPN이 있는지 확인합니다. DNS 모드나 네트워크 설정을 한꺼번에 바꾸기보다는 현재 값을 기록한 뒤 하나씩 시험하고, 문제가 해결되지 않으면 기존 값으로 되돌립니다. 계정 인증 오류가 함께 보인다면 프록시만 원인이라고 단정하지 말고 앱을 최신 상태로 유지하고 로그인 세션을 다시 확인하되, 인증 정보를 로그나 공개 화면에 붙여 넣지 마세요.
테스트가 끝나면 임시로 적용한 전역 모드, TUN 설정, 노드 선택, 규칙을 정리합니다. 원인을 찾지 못한 상태에서 여러 설정을 그대로 남겨 두면 다음 업데이트나 네트워크 전환 때 다른 앱까지 영향을 받을 수 있습니다. 프로필을 직접 수정했다면 변경한 줄과 이유를 기록하고, 앱 또는 Clash 코어 업데이트 후에는 새 연결 로그를 다시 확인합니다. 회사 네트워크에서는 보안 제품이나 프록시 정책이 앱 트래픽을 제한할 수 있으므로, 정책을 우회하려 하기보다 관리자에게 허용된 접속 방법을 문의하는 편이 안전합니다.
Codex 앱만 실패할 때는 브라우저 성공 여부만 보고 전체 네트워크를 바꾸기보다, 시스템 프록시 적용 여부와 로그의 규칙 매칭, 실제 노드 상태를 차례로 확인하는 것이 빠릅니다. 일부 클라이언트는 시스템 프록시와 TUN 설정을 찾기 쉬운 화면에 제공하지만, 구형 포크나 단순 프록시 도구는 앱별 라우팅 확인과 연결 로그가 부족해 원인을 좁히기 어려울 수 있습니다. Clash V.CORE는 프록시 상태와 규칙·노드 점검을 한 흐름으로 확인하기에 편리하므로, 기존 도구에서 경로를 추적하기 어렵다면 다운로드 페이지에서 Clash V.CORE를 확인해 보세요.