개발 및 AI · Clash 기술 블로그

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

Codex App 또는 CLI에서 Reconnecting이 반복되면 먼저 서비스 장애를 제외하세요. 그런 다음 Clash 연결 기록으로 시스템 프록시, WebSocket 및 HTTP 프록시 경로를 확인하고 롤백 가능한 단계에 따라 수정합니다.

본문 읽기블로그로 돌아가기
  • Codex
  • Clash Verge Rev
  • Reconnecting
  • WebSocket
  • 프록시 점검
이 글의 목차
게시일
예상 읽기 시간
약 9분

짧은 요청에서도 재연결되면 먼저 연결 경로로 문제 범위 제한

이 글은 Codex App 또는 CLI에서 간단한 요청을 보낸 뒤 화면에 Reconnecting 1/5부터 5/5까지 차례로 표시되고 마지막에 stream disconnected before completion이 나타나는 상황을 다룹니다. OpenAI 공식 issue #23061에 같은 오류 경로가 기록되어 있어 원인이 반드시 프롬프트, 저장소 크기 또는 컨텍스트 길이에 있는 것은 아닙니다.

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

비교 결과에 따라 먼저 분류

증상가능성이 높은 중단 지점계속 확인할 항목
OpenAI 상태 페이지에도 동시에 장애가 보고됨서버 측 이벤트복구를 기다린 뒤 다시 테스트
App은 실패하지만 같은 네트워크의 CLI는 사용 가능두 인터페이스의 프록시 연결 방식이 다름버전과 실행 방식 비교
짧은 응답은 성공하지만 긴 응답 중간에 재연결WebSocket 또는 프록시 장기 연결이 조기에 종료됨443, TLS와 시간 초과 확인
App과 CLI가 모두 Clash 연결 페이지에 나타나지 않음요청이 현재 프록시 진입점에 들어오지 않음시스템 프록시, TUN 또는 포트 확인
Codex 스트리밍 응답의 프록시 경로
  1. Codex App 또는 CLI로그인, HTTPS와 스트리밍 요청 시작
  2. 시스템 프록시, 환경 변수 또는 TUN요청이 Clash에 유입되는지 결정
  3. Clash 규칙과 노드chatgpt.com의 실제 외부 경로 선택
  4. OpenAI WebSocket443 포트에서 모델 스트리밍 연결 유지

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

상태 페이지와 다른 네트워크로 공통 장애 배제

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

상태 페이지가 정상이라면 같은 짧은 요청과 계정을 고정하고 현재 Clash 노드, 정상 작동을 확인한 다른 노드, 모바일 핫스팟 또는 기업 게이트웨이를 거치지 않는 네트워크에서 각각 테스트합니다. 네트워크를 바꾸자마자 복구된다면 Codex 작업을 삭제하지 말고 로컬 프록시나 회사 네트워크를 계속 확인해야 합니다.

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

  1. 정확한 오류 기록

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

  2. 최소 요청 고정

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

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

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

  4. 기존 노드 복원

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

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를 종료하고 임시 프록시를 끄면 시스템 네트워크가 기존 상태로 복구됨

참고 자료