왜 모바일 Codex만 간헐적으로 무너져 보일까?

2026년 들어 OpenAI Codex가 iOS·Android용 워크플로에 더 깊게 들어오면서, “데스크톱 에디터에서는 괜찮은데 휴대폰 Codex 앱만 로그인 직후 타임아웃”, “동일 Wi-Fi에서 스트리밍은 되는데 Codex 요청만 실패” 같은 리포트가 늘었습니다. 원인은 단일 버그라기보다 모바일 네트워크 스택이 데스크톱보다 공격적으로 전환 배터리·무선 링크 품질을 바꾸고, Codex 계열 클라이언트가 OpenAI API·실시간 채널을 짧은 간격으로 재호출하기 때문입니다. 브라우저 탭은 PAC·확장·자체 QUIC 설정으로 우회 경로를 숨기지만, 네이티브 앱 SDK는 OS 기본 라우팅과 DNS 캐시에 더 바짝 붙습니다.

이 글은 의료·금융 같은 규제 산업별 예외를 논하지 않고, 개발자와 파워 유저가 재현 가능한 순서로 접근한다는 전제에서 Clash Verge Rev(Mihomo 코어)를 기준으로 설명합니다. 핵심은 세 축입니다. 첫째, 구독 규칙만으로 부족할 때 도메인 Override로 Codex·OpenAI 호스트를 명시적으로 원하는 프록시 그룹에 태웁니다. 둘째, 시스템 프록시를 무시하는 라이브러리까지 묶으려면 TUN 모드가 현실적인 레버입니다. 셋째, 이름 해석이 ISP 리졸버로 새면 패킷이 PROXY에 닿기 전에 실패하므로 DNS 정렬을 같은 실험 번들에 넣습니다. 이미 기본기가 있다면 Clash Verge Rev 구성 튜토리얼의 Profiles·Rule 용어부터 맞춰 읽으면 더 빠릅니다.

엔드포인트 호스트 이름과 모델 이름(GPT-5.5 등)은 제품 업데이트에 따라 바뀔 수 있습니다. 본문 규칙 예시는 패턴 이해용이며 운영 환경에서는 Verge Rev 연결 로그에 나온 실제 DEST 문자열을 따라야 합니다.

Clash Verge Rev를 어디에 두어야 모바일 Codex에 닿나?

Clash Verge Rev는 주로 Windows·macOS용 GUI 클라이언트입니다. 따라서 휴대폰 자체에 동일 패키지를 설치하는 그림보다, 아래 같은 배치가 일반적입니다. 첫째, 집·사무실에서 항상 켜 두는 미니 PC·노트북 게이트웨이에 Verge Rev를 돌리고, 스마트폰은 그 LAN의 Wi-Fi만 사용합니다. 둘째, 동일한 Mihomo YAML을 공유하는 Android 측 호환 클라이언트를 쓰는 경우 — 이 경우 UI 이름은 다르지만 Rule·TUN·DNS 개념은 같습니다. 셋째, iOS는 샌드박스와 VPN 프로파일 정책 때문에 데스크톱과 1:1 대응이 어렵기 때문에, 정책·계정 제약을 확인한 뒤 허용된 클라이언트 또는 게이트웨이 우회를 고려해야 합니다.

즉 이 튜토리얼의 “TUN을 켠다”는 문장은 Verge Rev가 실행되는 장치 기준입니다. 폰이 최종 클라이언트라면 Wi-Fi 경로 곳곳에서 이미 그 장치 트래픽이 게이트웨이 TUN을 통과하도록 라우팅·방화벽이 정리되어 있어야 합니다. 반대로 LTE만 쓰는 외근 장면에서는 노트북 테더링 후 노트북 측 Verge Rev를 켜는 식으로 축을 단순화하는 편이 디버깅에 유리합니다.

증상을 표로 바꾸기

감으로만 “불안하다”고 말하면 노드 교체와 규칙 수정이 도박처럼 섞입니다. 아래 항목을 한 페이지 표에 적습니다.

  • 앱·모델 축: Codex 빌드 번호, 로그인 세션 길이, GPT-5.5 같은 모델 문자열을 명시합니다.
  • 네트워크 축: Wi-Fi SSID, 듀얼 SIM 중 활성 회선, 저전력 모드·데이터 절약 여부를 함께 적습니다.
  • 실패 유형: 즉시 끊김, 30~60초 후 타임아웃, 재시도 폭주, WebSocket 업그레이드 실패 등으로 나눕니다.
  • 동시 대조: 같은 시각에 브라우저에서 동일 계정 웹앱이 성공하는지, 데스크톱 Codex 확장만 성공하는지 기록합니다.

표가 채워지면 “회선 품질 문제인지, 규칙 매칭 문제인지, DNS 문제인지”를 가르는 첫 분기가 선명해집니다. 특히 주말 피크 시간대에만 지터가 커지는 패턴은 노드 교체로 커버되는 경우가 많고, 평일 오전에만 실패한다면 회사 프록시나 SSL 검사와 겹칠 확률이 있습니다.

타인 네트워크나 회사 단말에서 패킷 덤프·로그 수집은 정책 위반이 될 수 있습니다. 허용된 관측 수단과 데이터 보존 규정을 먼저 확인하세요.

1단계: 모바일 증상 패키지와 네트워크 축 정의

설정을 건드리기 전에 재현 번들을 고정합니다.

  1. Codex 앱에서 가능한 경우 디버그·버전 화면을 캡처하고, 실패 직전의 정확한 시각(타임존 포함)을 적습니다.
  2. Wi-Fi와 LTE를 각각 끈 상태에서 한 번씩 동일 작업을 반복해 어느 축에서만 깨지는지 확인합니다.
  3. 게이트웨이 시나리오라면 Verge Rev가 도는 PC에서 동시에 활성 연결 카드를 열어 Codex 세션과 시간을 맞춥니다.
  4. 간단한 참조 요청(예: 신뢰할 수 있는 헬스 체크 URL) 결과를 같은 행에 넣어 “전 인터넷 붕괴”와 “Codex 한정”을 분리합니다.

이 단계를 건너뛰면 나중에 Override를 추가했을 때 변인이 너무 많아져 회귀 테스트가 불가능해집니다. 재택·카페·코워킹처럼 장소가 바뀔 때마다 표를 복제해 행을 늘리면 축적 데이터가 쌓입니다.

2단계: Rule 모드와 활성 프로필 고정

Mihomo 라우팅의 기본 레일은 여전히 Rule입니다. Global은 단발 테스트용으로만 쓰고, 일상과 같은 상태를 재현하려면 Rule부터 고정합니다.

  • Profiles 화면에서 실제 구독과 Override 체인이 붙은 카드를 활성으로 둡니다.
  • 헤더 근처 모드 스위치가 Rule인지 시각적으로 확인하고, 테스트 중 불필요하게 Direct/Global을 오가지 않습니다.
  • 구독 자동 갱신 직후라면 리로드를 한 번 눌러 이전 캐시와 섞이지 않게 합니다.

Rule 고정 뒤에도 일부 트래픽은 DIRECT로 새게 되어 있는데, 여기에 Codex 관련 호스트가 포함되면 필터링이 그대로 남습니다. 다음 Override 단계에서 명시적으로 PROXY 그룹으로 당깁니다.

3단계: OpenAI·Codex 트래픽용 Override 규칙

구독 제공 규칙이 넓게 잡혀 있거나 반대로 특정 REGION 태그에서 빠져 나간다면 Override Merge로 조각을 덧댑니다.

  1. Settings 또는 Profiles 하위에서 Override를 열고 새 파일 종류를 Merge로 지정합니다.
  2. 연결 로그에 나타난 호스트 접두사를 기준으로 규칙을 작성합니다.
  3. 아래 예시의 그룹 이름은 반드시 활성 YAML 안 실제 Selector 문자열로 교체합니다.
rules:
  - DOMAIN-SUFFIX,openai.com,OPENAI-GROUP
  - DOMAIN-SUFFIX,oaistatic.com,OPENAI-GROUP
  - DOMAIN-KEYWORD,openai,OPENAI-GROUP
  - DOMAIN-SUFFIX,chatgpt.com,OPENAI-GROUP

OPENAI-GROUP 자리가 오타 나면 조용히 기본 FALLBACK으로 떨어져 증상이 그대로입니다. 저장 후 Applies를 실행하고 디버그 패널에서 매칭된 규칙 이름이 기대한 줄인지 확인하세요. 과도하게 넓은 키워드는 국내 CDN까지 불필요하게 태워 지연만 키우므로, 먼저 좁힌 뒤 필요할 때만 확장합니다.

스플릿 라우팅과 업무 트래픽 분리

동일 프로필 안에서 회사 SaaS는 DIRECT, Codex·OpenAI만 PROXY로 보내고 싶다면 GEOIP·DOMAIN-SUFFIX 단위로 표를 나눠 순서를 명확히 합니다. 규칙 리스트는 위에서 아래로 매칭되므로 더 구체적인 사내 도메인 DIRECT 규칙을 OpenAI 규칙보다 위에 두는 식으로 배치해야 합니다. 이렇게 해야 “분류”라는 말이 설정 파일에서도 기하학적으로 드러나고, 나중에 동료에게 공유할 때 설명 비용이 줄어듭니다.

4단계: TUN으로 비프록시 SDK 경로 포함

일부 모바일 네이티브 스택은 시스템 HTTP 프록시를 무시합니다. 게이트웨이 장치에서 TUN Mode를 켜면 해당 트래픽까지 가상 어댑터 레벨에서 같은 코어로 들어옵니다.

  1. Settings에서 TUN 토글을 활성화합니다.
  2. Windows는 관리자 권한 프롬프트, macOS는 시스템 확장 승인이 필요할 수 있습니다.
  3. 스택 프리셋이 있다면 기본 Mixed부터 시작하고 변경 전후 표를 분리합니다.
  4. 활성화 직후 Codex 동작과 참조 curl 결과를 다시 입력합니다.

TUN은 만능이 아닙니다. 동일 머신에서 기업 VPN 어댑터가 이미 상위 우선순위를 잡고 있으면 오히려 블랙홀처럼 느껴질 수 있어, 한 레이어만 남긴 대조 실험이 필요합니다. 회사 보안 정책으로 TUN이 금지된 장비에서는 본 가이드를 억지로 적용하지 말고 허용된 경로를 우선합니다.

5단계: DNS 정렬(fake-ip·fallback)

DNS 질문이 여전히 ISP 리졸버로 향하면 규칙이 아무리 정교해도 첫 패킷부터 엇나갑니다.

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.google/dns-query
    - https://dns.cloudflare.com/dns-query
  fallback:
    - https://8.8.8.8/dns-query
  fake-ip-filter:
    - '+.lan'

Override 반영 후에도 이전 Fake-IP가 남아 있으면 코어 재시작이 필요할 수 있습니다. 스트리밍 호환 문제로 Redir-Host로 바꿀 때는 동일 표를 새로 그려 전후를 비교하세요. 모바일 특유의 캐리어 NAT 환경에서는 DoH 지연이 커질 수 있으므로 nameserver 후보를 과도하게 늘리기보다, 검증된 두 세트만 두고 지터를 측정하는 편이 안정적입니다.

6단계: 모바일·게이트웨이에서 종단 검증

규칙을 넣었다면 숫자로 다시 확인합니다. Android에서 Termux 등으로 허용된 환경을 쓸 수 있다면 짧은 TLS 확인 명령을 Codex 테스트와 같은 순간에 실행합니다. iOS는 시스템 제약이 크므로 실무에서는 게이트웨이 PC에서 동일 호스트로 curl을 돌려 패턴을 맞추는 경우가 많습니다.

curl -w '%{http_code} %{time_connect} %{time_starttransfer}' -o /dev/null https://YOUR_DEBUG_HOST

연결 시간은 안정적인데 상태 코드만 흔들리면 업스트림 레이트 리밋이나 인증 헤더 문제를 의심하고, 시간 자체가 들쭉날쭉하면 노드 품질이나 무선 링크 혼잡을 의심합니다. 표에 열을 하나 더 만들어 패치 전후를 나란히 적어 두면 “설정 때문인지 회선 때문인지”가 회고 때 분명해집니다.

Codex 세션이 길어질수록 연결 재사용 특성이 달라질 수 있어, 짧은 스모크 테스트만으로 성공을 단정하지 말고 실제 작업 길이만큼 재현해 보세요.

7단계: Proxies 지연 테스트와 그룹 선택

설정 레이아웃이 정돈됐다면 병목이 노드 풀인지 검증합니다.

  • Proxies 화면에서 일괄 지연 테스트를 실행하고 지터가 낮은 후보를 고릅니다.
  • 구독에 URL-Test·Fallback 그룹이 포함돼 있다면 Codex 장시간 세션에 맞춰 타이머 값이 과도하게 공격적이지 않은지 확인합니다.
  • 그룹 이름을 바꾼 경우 Override 규칙 문자열도 함께 업데이트합니다.

간헐 실패가 특정 시간대에만 발생한다면 표에 시간대 칸을 추가하고, 그 시간대에 자동으로 교체되는 업링크가 있는지 확인합니다. 이때 클린한 규칙 세트를 유지하면 운영 공유가 쉬워집니다.

8단계: 설정 스냅샷으로 회귀 구분

Overrides 파일 이름, 규칙 태그, DNS 모드 문자열, 고정한 Proxies 그룹, 성공·실패에 대한 최소 curl 출력을 한 표에 묶어 두면 며칠 뒤에도 같은 실험을 복제하기 쉽습니다. Codex 앱이나 구독이 올라갈 때마다 행만 갱신하면 변인 통제가 유지됩니다. GPT 계열 모델 문자열이 바뀔 때도 동일한 표 위에 메모하면 GPT-5.5 전후 차이를 회선 문제와 분리하는 데 도움이 됩니다.

문서화 습관이 생기면 팀 단위로도 “어제 설정 밀어넣고 오늘 장애” 같은 혼선을 줄일 수 있습니다. 특히 재택·현장을 오가며 여러 프로필을 쓰는 경우 프로필 이름 규칙을 문서 첫 줄에 적어 두세요.

자주 묻는 질문

iOS에서 Clash Verge Rev를 직접 설치할 수 있나요?

일반 사용자 관점에서는 데스크톱용 Verge Rev 패키지와 같은 자유도로 Mihomo TUN을 깔기 어렵습니다. 허용된 클라이언트가 있다면 동일 YAML 철학을 공유하는지 확인하고, 없다면 게이트웨이 PC 구성이 현실적인 타협입니다.

Codex만 실패하고 다른 앱은 정상인데 왜 그런가요?

Codex는 OpenAI 백엔드와의 연속 요청이 많아 TLS·DNS·HTTP 버전 조합에 더 민감합니다. 규칙에서 해당 호스트가 DIRECT로 새거나 불안정한 노드로만 붙으면 증상이 Codex에 집중되어 보입니다.

TUN과 회사 VPN·MDM이 같이 켜지면 더 불안해집니다.

가상 NIC 우선순위와 라우팅 테이블 충돌이 흔한 원인입니다. 정책 범위 안에서 한쪽만 켠 실험부터 하세요.

GPT-5.5 계열 모델만 문제인 것처럼 느껴집니다.

모델 플래그가 바뀌면 게이트웨이 쿼터 메시지와 레이트 리밋도 함께 움직입니다. 규칙·노드를 고정한 채 모델만 바꿔 병렬 표를 만들면 원인 분기가 쉬워집니다.

정리하면

모바일 Codex 불안 이슈를 단순히 “앱 버그”나 “일시적 장애”로만 치부하면 같은 타임아웃이 몇 주 뒤에 되풀이됩니다. 반면 단발성 VPN 앱처럼 화면에서 한 번 켜고 잊는 방식은 새 OS 업데이트마다 경로가 바뀌어 재디버깅 비용이 큽니다. 상용 SaaS형 원클릭 VPN은 편하지만 세분화된 RULE·Override·DNS 로그를 사용자에게 열어 주지 않아 Codex처럼 호스트 단위로 깨지는 문제를 패턴화하기 어렵습니다.

Clash Verge Rev는 Mihomo 계열 특유로 규칙 분류와 TUN 레이어를 한 화면에서 조정할 수 있어, Wi-Fi 게이트웨이 뒤에서 모바일 Codex 트래픽을 같은 회선으로 묶고 표로 관리하기 좋습니다. 다만 영문 UI 학습 비용과 회사 단말 정책 충돌은 현실적인 한계입니다. 운영 허용 범위 안에서 출발점을 단순화하고 싶다면 공식 배포와 문서가 정돈된 Clash 클라이언트 라인업부터 맞춘 뒤 Verge Rev로 옮겨 타도 됩니다.

플랫폼별 Clash 무료 다운로드 — Codex 모바일도 규칙 기반 회선부터 맞추기 →