개발 및 AI · Clash 기술 블로그

Codex가 반복해서 Reconnecting될 때 해결 방법: Clash 프록시 점검

Codex App이나 CLI가 계속 Reconnecting을 표시하면 서비스 상태, Clash 연결 기록, 시스템 프록시, WebSocket 및 HTTP 프록시를 확인하세요. 실패한 요청을 고정해 재시험하고 완전한 응답과 종료 후 네트워크 연결을 검증하세요.

본문 읽기블로그로 돌아가기
  • Codex
  • Clash Verge Rev
  • Reconnecting
  • WebSocket
  • 프록시 점검
이 글의 목차
글 작성자
Clash 공식
게시일
업데이트 날짜
예상 읽기 시간
약 9분

짧은 프롬프트에도 재연결이 반복된다면 입력을 더 줄이거나 세션을 정리해도 도움이 되지 않을 수 있습니다. 웹페이지가 열리거나 로그인에 성공해도 응답에 쓰는 연결이 안정적으로 유지된다는 뜻은 아닙니다. 같은 요청을 유지하면서 서비스 상태, 프록시 기록과 출구별 결과를 비교해야 합니다.

짧은 프롬프트에서도 Reconnecting이 나타날 때

Codex App 또는 CLI에서 Reconnecting 1/5부터 5/5까지와 마지막 stream disconnected before completion을 기록하세요. OpenAI 공식 issue #23061에도 간단한 프롬프트에서 같은 현상이 기록되어 있지만 프롬프트, 저장소 크기 또는 컨텍스트 길이가 원인이라고 단정할 수는 없습니다.

Codex의 일반 HTTPS 요청이 성공해도 스트리밍 응답이 안정적이라는 뜻은 아닙니다. OpenAI 네트워크 문서에 따르면 Codex는 wss://chatgpt.com/을 통해 보안 WebSocket도 연결합니다. 앱의 프록시 연결, Clash 규칙, 노드 외부 경로와 장기 연결 정책 중 어느 단계에서든 응답이 중단될 수 있습니다.

Codex 스트리밍 응답의 프록시 경로
  1. Codex App 또는 CLI로그인, HTTPS와 스트리밍 요청 시작
  2. 시스템 프록시, 환경 변수 또는 TUN요청이 Clash에 유입되는지 결정
  3. Clash 규칙과 노드chatgpt.com의 실제 외부 경로 선택
  4. OpenAI WebSocket443 포트에서 모델 스트리밍 연결 유지

짧은 요청은 성공하지만 응답 도중 반복해서 재연결된다면 흔한 중단 지점은 프롬프트 자체가 아니라 앱의 프록시 연결, 규칙을 통한 외부 경로 또는 WebSocket 장기 연결 사이에 있습니다.

재연결 원인은 서비스 장애, 노드, 로컬 네트워크 중 무엇인가요?

status.openai.com에 현재 처리 중인 ChatGPT 또는 Codex 이벤트가 있는지 먼저 확인하세요. 상태 페이지에 명확한 장애가 있다면 오류 발생 시간을 보존하고 복구를 기다립니다. 이때 많은 노드를 바꾸거나 규칙을 다시 작성하면 기존 비교 조건만 손상됩니다.

상태 페이지가 정상이라면 같은 짧은 프롬프트와 계정으로 서로 다른 네트워크 출구를 비교하세요. 네트워크를 바꾸면 정상으로 돌아오는 경우 로컬 프록시나 회사 네트워크를 계속 점검하고 Codex 세션은 삭제하지 마세요.

재현 가능한 세 가지 비교 구성

  1. 정확한 오류 기록

    Reconnecting 횟수, 실패 URL, 발생 시각, Codex App과 CLI 버전을 저장하고 작업 내용이나 토큰은 공개하지 마세요.

  2. 최소 요청 고정

    새 작업에서 같은 짧은 요청을 보내고 긴 컨텍스트, 도구 호출과 저장소 스캔이 네트워크 판단을 방해하지 않도록 합니다.

  3. 외부 경로는 한 번에 하나만 변경

    정상 작동을 확인한 Clash 노드 하나로 먼저 바꾼 뒤 모바일 핫스팟으로 전환합니다. 매번 같은 오류가 나타나는지 관찰하세요.

  4. 기존 노드 복원

    비교를 마친 뒤 기존 정책 그룹으로 돌아가 이후 결과가 기록하지 않은 새 외부 경로에서 나오지 않도록 합니다.

비교 결과에 따라 다음 점검 항목 선택

증상문제가 발생했을 가능성이 높은 부분계속 확인할 항목
OpenAI 상태 페이지에도 동시에 장애가 보고됨서버 측 이벤트복구를 기다린 뒤 다시 테스트
App은 실패하지만 같은 네트워크의 CLI는 사용 가능두 인터페이스의 프록시 연결 방식이 다름버전과 실행 방식 비교
짧은 응답은 성공하지만 긴 응답 중간에 재연결WebSocket 또는 프록시 장기 연결이 조기에 종료됨443, TLS와 시간 초과 확인
App과 CLI가 모두 Clash 연결 페이지에 나타나지 않음요청이 현재 프록시 진입점에 들어오지 않음시스템 프록시, TUN 또는 포트 확인

Clash 연결 페이지에서 Codex가 실제로 프록시에 유입되는지 확인

Clash Verge Rev의 연결 페이지를 열고 기존 필터를 지운 뒤 Codex에서 새 요청을 한 번 보냅니다. chatgpt.com과 관련 OpenAI 도메인을 찾아 적용 규칙, 정책 그룹과 실제 노드를 기록하세요. 브라우저 트래픽만 보인다고 Codex App 또는 CLI가 같은 경로를 사용한다는 뜻은 아닙니다.

평소에는 계속 Rule 모드를 사용해야 합니다. 누락된 규칙이 원인인지 판단하기 위해 잠시 Global로 전환하고 같은 노드로 다시 테스트할 수 있습니다. Global에서는 복구되고 Rule에서는 실패한다면 요청은 Clash에 들어오며 문제는 규칙 또는 정책 선택에 있습니다. Codex를 더 수정할 필요가 없습니다. 테스트 후 즉시 기존 모드로 돌아가세요.

Codex 요청이 나타나고 예상한 노드를 사용함

요청이 프록시에 도달했습니다. WebSocket, TLS 검사와 장시간 연결의 시간 초과를 계속 확인하세요.

요청은 나타나지만 DIRECT에 일치

잠시 Global로 비교한 뒤 연결 기록을 바탕으로 누락된 규칙을 추가하세요.

새 Codex 연결이 전혀 없음

해당 프로세스가 시스템 프록시를 읽지 않았거나 CLI가 현재 터미널의 프록시 변수를 상속하지 않았을 수 있습니다.

모든 도메인이 계속 timeout

노드나 네트워크를 먼저 바꾸고 전체 업스트림 장애를 Codex 전용 문제로 간주하지 마세요.

App과 CLI 버전 및 실행 환경

Codex 공식 문제 해결 안내에 따르면 데스크톱 App과 CLI의 버전이 다를 수 있습니다. 양쪽 버전을 먼저 기록하고 같은 네트워크와 노드에서 같은 짧은 요청을 보내세요. App은 성공하고 CLI는 실패하거나 그 반대인 경우 계정과 OpenAI 서비스만이 유일한 변수가 아니라는 뜻입니다.

현재 CLI 버전 확인, macOS에서는 App 내장 버전도 함께 확인 가능
codex --version
/Applications/Codex.app/Contents/Resources/codex --version

버전과 결과 해석 방법

비교판단다음 단계
App과 CLI 버전이 다름이전 버전 쪽을 먼저 업데이트한 뒤 재검증노드와 요청은 그대로 유지
CLI는 사용 가능하지만 App은 계속 재연결App이 터미널 환경 변수를 따르지 않을 수 있음TUN 또는 시스템 프록시로 별도 비교
App은 사용 가능하지만 CLI는 계속 재연결현재 shell 프록시 변수 또는 실행 환경 이상변수와 실제 HTTP 포트 확인
양쪽 모두 같은 단계에서 실패공통 노드, 규칙 또는 WebSocket 문제일 가능성이 큼네트워크 제어 계속 확인

Codex의 WebSocket이 443 포트에서 연결을 유지하도록 허용

OpenAI 공식 네트워크 권장 사항에 따르면 프록시, 방화벽 또는 보안 게이트웨이는 chatgpt.com이 TCP 443에서 표준 Upgrade: websocket 핸드셰이크를 완료하도록 허용해야 합니다. 웹페이지와 로그인은 되지만 응답이 생성 도중 계속 끊긴다면 네트워크 관리자에게 WebSocket 유휴 시간 초과, 최대 메시지 크기와 장기 연결의 조기 종료 여부를 확인하도록 요청하세요.

기업 네트워크에서 TLS 검사를 사용한다면 잘못된 인증서로 바꾸거나 핸드셰이크를 수정하거나 일반 HTTPS만 허용하는지도 확인해야 합니다. 가장 유용한 비교는 같은 계정과 Codex 버전으로 모바일 핫스팟을 사용하는 것입니다. 핫스팟은 안정적이고 회사 네트워크만 실패할 때 네트워크 정책 문제로 전달하세요.

관리자에게 전달할 최소 확인 항목

  • chatgpt.com의 TCP 443과 WebSocket Upgrade 허용
  • 장기 연결이 지나치게 짧은 idle timeout으로 조기 종료되지 않음
  • TLS 검사 신뢰 체인이 HTTPS, 로그인과 보안 WebSocket에서 일관됨
  • 공식 목록의 ChatGPT, OpenAI와 정적 리소스 도메인이 변경되지 않음
  • 모바일 핫스팟 비교로 계정, 프롬프트와 로컬 버전 문제를 배제함

현재 터미널에서만 Clash의 HTTP 프록시 진입점 테스트

OpenAI Codex issue #20844는 아직 닫히지 않은 사용자 보고입니다. 같은 프록시 스택에서 SOCKS5를 사용할 때 stream disconnected가 발생했지만 명시적인 HTTP_PROXY와 HTTPS_PROXY를 사용하자 복구되었습니다. 이는 공식적으로 보장된 일반 수정이 아니지만 SOCKS 경로와 HTTP 경로의 동작이 다른지 판단하는 데 사용할 수 있습니다.

Clash Verge Rev 설정에서 HTTP 또는 Mixed 포트를 먼저 확인하세요. 아래의 7897은 예시일 뿐이므로 로컬 실제 포트로 바꿔야 합니다. 변수는 현재 터미널에만 설정하고 처음부터 shell 구성이나 시스템 환경에 넣지 마세요.

macOS 또는 Linux: 7897을 현재 HTTP 또는 Mixed 포트로 교체
export HTTP_PROXY=http://127.0.0.1:7897
export HTTPS_PROXY=http://127.0.0.1:7897
export http_proxy="$HTTP_PROXY"
export https_proxy="$HTTPS_PROXY"
unset ALL_PROXY all_proxy
codex
Windows PowerShell: 7897을 현재 HTTP 또는 Mixed 포트로 교체
$env:HTTP_PROXY="http://127.0.0.1:7897"
$env:HTTPS_PROXY="http://127.0.0.1:7897"
Remove-Item Env:ALL_PROXY -ErrorAction SilentlyContinue
codex

CLI가 즉시 안정되고 연결 페이지에 chatgpt.com이 표시됨

당분간 해당 터미널에서 작업을 계속하고 App의 트래픽을 TUN으로 처리해야 하는지 확인하세요.

HTTP는 작동하지만 SOCKS5에서는 스트림이 계속 끊김

검증된 HTTP 또는 Mixed 진입점을 우선 사용하고 관련 공식 issue의 후속 수정을 확인합니다.

두 프록시 모두 실패하지만 모바일 핫스팟에서는 정상

Clash 노드, 규칙과 WebSocket 전달을 확인하고 변수를 시스템에 영구적으로 기록하지 마세요.

새 프로세스가 여전히 연결 페이지에 나타나지 않음

포트가 잘못되었거나 같은 터미널에서 명령을 실행하지 않았을 수 있습니다. 프로세스를 종료한 뒤 설정을 확인하고 다시 시도하세요.

터미널 변수 해제 후 스트리밍 응답 재확인

테스트가 효과가 없거나 시스템 프록시로 돌아가려면 이번에 시작한 Codex를 먼저 종료하고 현재 터미널을 닫아 임시 변수를 취소합니다. 변수를 shell 구성이나 Windows 사용자 환경에 기록했다면 이번에 추가한 항목을 삭제하고 새 터미널을 여세요. 기존 SOCKS, HTTP와 TUN이라는 세 가지 불확실한 경로를 동시에 유지하지 마세요.

App이 TUN에서만 안정적이라면 되돌릴 수 있는 임시 접속 방식으로 사용하고, TUN을 꺼도 시스템 프록시를 복원할 수 있는지 확인하세요. 이후 Codex 또는 Clash Verge Rev를 업데이트하면 같은 점검 목록으로 다시 테스트한 뒤 TUN을 계속 유지할지 결정하세요.

최종 검증 체크리스트

  • App과 CLI에서 짧은 요청을 각각 한 번 보내도 더 이상 Reconnecting 횟수가 늘지 않음
  • 비교적 긴 응답을 연속 생성해도 stream disconnected before completion이 나타나지 않음
  • Clash 연결 페이지에서 chatgpt.com이 예상한 규칙과 고정 노드에 일치함
  • Codex를 종료하고 임시 프록시를 끄면 시스템 네트워크가 기존 상태로 복구됨

참고 자료