2026년 GPT-Realtime-2와 OpenAI Realtime API가 네트워크에서 다루는 것

2026년 5월 OpenAI가 GPT-Realtime 계열, 그중 GPT-Realtime-2를 공개하면서 OpenAI Realtime API에 대한 관심이 빠르게 올라갔습니다. 이 API는 짧은 REST 한 번 호출로 끝나지 않고, WebSocket으로 세션을 열어 스트리밍 오디오·텍스트 이벤트를 양방향으로 주고받습니다. 개발자 입장에서는 “SDK 예제 그대로 붙였는데 101 Switching Protocols 전에 끊긴다”, “30초쯤 말하다 갑자기 세션이 닫힌다”, “첫 응답까지 2~3초씩 밀린다” 같은 증상이 한꺼번에 터지곤 합니다.

겉으로는 모두 “Realtime 연결 실패”로 보이지만, 실제 TLS 연결은 api.openai.com의 Realtime 엔드포인트, 짧은 REST 토큰·세션 준비 호출, 때로는 openai.com·auth.openai.com 인증 경로, 그리고 정적 자산·CDN까지 한 앱 안에서 여러 번 갈라집니다. 그중 한 호스트만 DIRECT로 떨어지거나 다른 GEOIP 레인으로 붙으면 WebSocket 핸드셰이크는 성공해도 이후 오디오 프레임이 끊기거나, 반대로 핸드셰이크 단계에서 바로 실패하는 식으로 증상이 갈립니다. 본문은 ChatGPT 웹·API 분할 글과 Codex MCP 분할 글을 대체하지 않고, Realtime WebSocket 장기 연결에 특화된 Clash 분할 절차만 깊게 다룹니다.

전제: 회사·학교 정책이나 서비스 약관을 위반하는 우회는 다루지 않습니다. 이미 허용된 프록시 환경에서 연결 품질을 안정화하는 기술적 순서에 한정합니다.

ChatGPT 웹·Codex MCP 글과 무엇이 다른가

GPT-5.5 Instant × ChatGPT 글은 브라우저·앱 채팅의 SSE·CDN 패턴을 중심으로 합니다. Codex MCP 글은 IDE 도구 호출·짧은 폴링형 요청이 섞인 패턴을 다룹니다. 반면 OpenAI Realtime API는 단일 WebSocket이 수 분~수십 분 유지되며, 그 안에서 오디오 청크가 연속적으로 흐릅니다. 중간 박스·노드·회사 방화벽의 TCP idle timeout·HTTP/2 연결 재사용 정책과 맞물리면 “REST API는 되는데 Realtime만 끊긴다”는 전형적인 패턴이 나옵니다.

또한 Realtime 데모는 Node.js·Python SDK, Electron·React Native 래퍼 등 시스템 프록시를 따르지 않는 런타임에서 자주 돌아갑니다. 브라우저에서 ChatGPT 음성은 정상인데 로컬 SDK만 실패하면, 규칙 YAML 자체보다 출구 불일치·TUN 미적용을 먼저 의심하는 편이 낫습니다.

증상을 세 바구니로 나누기

현장에서는 아래처럼 나누면 원인을 빠르게 좁힙니다.

핸드셰이크 실패: wss://api.openai.com/... 업그레이드 직후 403·502·TLS 오류·즉시 ECONNRESET. 규칙 오매칭·DIRECT 누락·DNS fake-ip·인증 헤더 문제를 의심합니다.
세션 중간 끊김: 연결은 되지만 20~60초·수 분 후 1006·1011 등으로 종료. TCP idle·노드 품질·중간 프록시의 WebSocket 프록시 미지원·규칙 전환(노드 재선택)을 봅니다.
고지연·버퍼링: 연결은 유지되나 첫 응답·턴 교체가 1초 이상 밀림. 노드 RTT·리전 편향·동일 세션 내 다른 호스트가 느린 레인으로 새는 경우를 확인합니다.

세 경우 모두 사용자 로그에는 “Realtime WebSocket error” 한 줄로 합쳐지므로, Clash 연결 로그의 FQDN·매칭 정책·프록시 이름이 핵심 증거가 됩니다. 재현 직후 로그를 캡처해 두세요.

WebSocket·TCP 관점에서 Realtime이 까다로운 이유

OpenAI Realtime API의 기본 전송은 TLS 위 WebSocket(TCP)입니다. UDP/RTP 기반 보이스는 Discord 등 다른 서비스에서 두드러지며, Realtime에서는 Discord UDP 분할 글의 UDP 절차를 그대로 가져올 필요는 없습니다. 대신 다음을 기억하면 됩니다.

첫째, WebSocket은 HTTP 업그레이드 후 장시간 단일 TCP를 유지합니다. 일반 REST보다 중간 장비의 idle timer에 더 민감합니다. 둘째, 스트리밍 오디오는 작은 패킷이 자주 와서 지터에 민감합니다. RTT가 높은 노드는 체감 지연이 REST보다 훨씬 크게 느껴집니다. 셋째, SDK가 wss://와 짧은 https:// 호출을 번갈아 쓰면, 둘이 다른 Clash 그룹으로 나가 세션이 엉망이 될 수 있습니다.

팁: Realtime 세션 중 Clash 대시보드에서 api.openai.com 연결이 갑자기 다른 노드로 바뀌면(예: url-test 재선택) WebSocket이 끊길 수 있습니다. Realtime 전용 그룹은 select 고정 또는 tolerance가 큰 url-test를 검토하세요.

자주 보는 Realtime·OpenAI 도메인 패턴

코어 Realtime: 대부분의 SDK 예제는 wss://api.openai.com/v1/realtime 계열(모델·쿼리 파라미터는 버전에 따라 다름)로 붙습니다. REST로 세션·모델 메타를 준비하는 호출도 같은 api.openai.com에 모입니다. 이 축은 OpenAI-Realtime 같은 전용 proxy-groups로 묶고, 일반 ChatGPT 웹 트래픽과 분리하면 “채팅은 되는데 SDK Realtime만 실패”를 빠르게 좁힐 수 있습니다.

인증·웹: auth.openai.com·openai.com·chatgpt.com은 브라우저 데모·OAuth 플로에 등장합니다. API 키만 쓰는 서버 앱은 덜 보이지만, Electron 셸이 로그인 창을 띄우면 분리 규칙이 필요합니다.

정적·CDN: oaistatic.com·oaiusercontent.com 등은 UI·샘플 에셋에 붙습니다. 광역 GEOIP에 먼저 걸리면 데모 페이지만 깨지고 뒤이어 Realtime 테스트가 실패하는 것처럼 보일 수 있습니다.

실험·베타: 2026년 GPT-Realtime 시리즈 업데이트마다 서브패스·베타 호스트가 바뀔 수 있습니다. 실패 시점 FQDN을 그대로 DOMAIN 한 줄로 올려 두는 습관이 안전합니다. OpenAI는 배포·파티션에 따라 호스트가 달라질 수 있으므로, 아래 패턴은 예시이며 실측 로그로 보강해야 합니다.

TUN 모드 vs 시스템 프록시: SDK 앱은 어디로 나가나

Realtime 샘플을 Node.js·Python에서 돌릴 때, 런타임이 OS 시스템 프록시를 무시하는 경우가 많습니다. macOS·Windows에서 Clash mixed-port만 켜 두고 SDK를 실행하면 트래픽이 Clash를 우회해 DIRECT 또는 잘못된 회선으로 나갑니다. 이때 브라우저 ChatGPT 음성은 정상이어도 SDK Realtime만 실패하는 전형적인 패턴이 나옵니다.

대응 순서는 보통 다음과 같습니다. (1) 터미널에서 HTTPS_PROXY·ALL_PROXY를 mixed-port에 맞춥니다. (2) 그래도 엇갈리면 TUN 모드로 커널 경로를 일관되게 코어에 태웁니다. (3) WSL2·Docker 안에서 SDK를 돌리면 호스트·게스트 프록시가 따로 놀 수 있으므로 WSL2 라우팅 글과 함께 봅니다. (4) Electron·네이티브 앱은 앱 자체 프록시 설정이 있는지 확인합니다.

회사 보안 에이전트와 TUN이 충돌하면 허용된 방법만 선택하세요. 글로벌 모드 vs 시스템 프록시 글도 출구 선택 참고용입니다.

proxy-groups와 rules 축약 예시

아래는 개념 예시입니다. 구독의 실제 proxies 이름으로 바꾸고, 로그에 보인 호스트를 한 줄씩 추가하세요. OpenAI-Realtime은 WebSocket·낮은 지터용 풀, OpenAI-WebAuth는 로그인용, OpenAI-Static은 CDN용으로 나누는 패턴이 자주 쓰입니다.

YAMLproxy-groups:
  - name: "OpenAI-Realtime"
    type: url-test
    url: "https://api.openai.com"
    interval: 300
    tolerance: 80
    proxies:
      - DIRECT
      # 저지연·WebSocket 안정 노드 (미국 서부/동부 등 실측 후 선택) ...

  - name: "OpenAI-WebAuth"
    type: select
    proxies:
      - DIRECT
      # 로그인·리다이렉트용 노드 ...

  - name: "OpenAI-Static"
    type: select
    proxies:
      - DIRECT
      # CDN·대용량용 노드 ...

rules:
  - DOMAIN-SUFFIX,api.openai.com,OpenAI-Realtime
  - DOMAIN-SUFFIX,auth.openai.com,OpenAI-WebAuth
  - DOMAIN-SUFFIX,openai.com,OpenAI-WebAuth
  - DOMAIN-SUFFIX,chatgpt.com,OpenAI-WebAuth
  - DOMAIN-SUFFIX,oaistatic.com,OpenAI-Static
  - DOMAIN-SUFFIX,oaiusercontent.com,OpenAI-Static
  # 실측 로그에서 추가한 DOMAIN/DOMAIN-SUFFIX ...
  # GEOIP·MATCH 등 기존 묶음보다 위에 두었는지 최종 확인

api.openai.com 한 줄이 REST·Realtime·일반 API를 모두 같은 레인으로 보냅니다. Realtime만 다른 노드가 필요하면, 로그에 베타 전용 호스트가 보일 때 DOMAIN으로 더 좁히세요. 규칙이 너무 촘촘하면 유지보수 부담이 커지므로, 규칙 분할 가이드에서 말한 위에서 아래 첫 일치 원칙 안에서 점진적으로 조정하는 것이 현실적입니다.

실측 절차: 로그부터 TUN·노드까지

다음 순서는 GPT-Realtime-2·Realtime WebSocket 재현을 줄이는 데 도움이 됩니다. 각 단계에서 새로 보인 호스트는 메모해 두었다가 Mihomo 프로필에 반영하세요.

Realtime SDK를 재현한 직후 Clash 연결 로그에서 목적지 FQDN과 매칭된 정책·프록시 그룹 이름을 적습니다. api.openai.com이 의도와 다른 그룹이면 규칙 순서부터 의심합니다.
같은 머신에서 curl -v https://api.openai.com와 WebSocket 테스트(공식 예제·websocat 등)로 TLS·지연 차이를 봅니다. 터미널 환경 변수와 IDE·데스크톱 앱 출구를 비교합니다.
enhanced-mode: fake-ip 프로필이면 fake-ip-filter에 api.openai.com·인증 호스트가 필요한지 확인합니다. IP로 바로 붙는 클라이언트는 도메인 규칙이 스킵되는 경우가 있습니다.
Clash mixed-port·시스템 프록시·Clash Verge 시스템 프록시 밀어 넣기가 SDK 런타임과 일치하는지 확인합니다. Node.js는 HTTPS_PROXY 유무가 브라우저와 다를 수 있습니다.
세션이 중간에 끊기면 Realtime 전용 그룹에서 노드를 select로 고정한 뒤 재시도합니다. url-test가 세션 중 노드를 바꾸면 WebSocket이 끊길 수 있습니다.
여전히 엇갈리면 TUN으로 전환해 커널 경로가 일관되게 코어를 통과하는지 비교합니다. DNS·분할 터널이 겹치면 증상이 바뀌는지가 중요한 힌트입니다.

주의: 출처가 불분명한 원격 RULE-SET은 OpenAI 호스트를 예기치 않게 다른 레인으로 보낼 수 있습니다. API 키·음성 데이터가 있는 머신에서는 신뢰할 수 있는 구독과 검증된 로컬 규칙을 우선하세요.

노드·리전 선택: Realtime에 맞는 RTT

OpenAI Realtime API는 양방향 오디오라 왕복 지연이 체감 품질에 직결됩니다. 일반 다운로드 속도가 빠른 노드라도 RTT가 높으면 Realtime에는 불리할 수 있습니다. 미국 서부(us-west)·동부(us-east) 등 OpenAI 엔드포인트와 지리적으로 가까운 풀을 후보로 두고, url-test의 url을 https://api.openai.com 또는 조직에서 허용하는 측정 URL로 맞춘 뒤 tolerance를 너무 좁히지 마세요.

한 노드에서 REST Chat Completions는 빠른데 Realtime WebSocket만 끊긴다면, 해당 노드·중계가 장시간 TCP·WebSocket 프록시에 약한 경우가 있습니다. 다른 노드로 바꾸거나, Realtime 전용 select 그룹으로 고정해 A/B 테스트하세요. 지연 테스트·DNS 트러블슈팅 글과 함께 보면 REST와 Realtime의 차이를 구분하기 쉽습니다.

구독 제공자별로 “AI 전용”·“스트리밍실측 로그와 세션 유지 시간을 우선하세요.

자주 묻는 질문

Q. ChatGPT 웹 음성은 되는데 Realtime API WebSocket만 실패합니다. A. 브라우저와 SDK 프로세스의 프록시·DNS 경로가 다르면 같은 계정·같은 api.openai.com이라도 서로 다른 Clash 정책으로 나갈 수 있습니다. 로그에서 실제 호스트와 매칭 그룹을 확인하고, TUN 또는 HTTPS_PROXY로 출구를 맞추세요.

Q. Realtime에 UDP 설정이 필요한가요? A. 기본 Realtime 경로는 TLS 위 WebSocket(TCP)입니다. UDP 이슈는 Discord 보이스 등 다른 프로토콜에서 더 흔합니다. Realtime에서는 TCP idle·노드·규칙 순서를 먼저 보세요.

Q. Clash Verge에서도 같은 YAML을 쓸 수 있나요? A. Mihomo·Clash Meta 코어를 쓰는 Clash Verge라면 본문의 proxy-groups와 rules를 그대로 옮길 수 있습니다. macOS·Windows에서 TUN·시스템 확장 권한만 OS에 맞추면 됩니다.

마무리

GPT-Realtime-2와 OpenAI Realtime API는 짧은 REST 호출 몇 번으로 끝나지 않습니다. Realtime WebSocket 장기 연결 위에서 스트리밍 오디오가 흐르기 때문에, ChatGPT 웹·Codex MCP와는 다른 네트워크 민감도를 가집니다. api.openai.com을 전용 Clash 분할 그룹으로 묶고, TUN·DNS·노드 RTT까지 한 흐름으로 점검하면 “핸드셰이크만 실패”·“말하다 끊김”·“첫 응답만 느림”을 훨씬 빠르게 좁힐 수 있습니다.

일반 VPN이나 브라우저 전용 확장은 SDK·WebSocket 장기 연결과 세분화된 api.openai.com 규칙을 함께 다루기 어렵고, DOMAIN-SUFFIX·전략 그룹 표현도 제한적인 경우가 많습니다. 반면 Clash 공식 사이트가 안내하는 Clash·Mihomo 계열 프로필은 DOMAIN-SUFFIX·url-test/select·DNS fake-ip-filter를 한 YAML에서 묶어 쓸 수 있어, 2026년처럼 GPT-Realtime 생태가 빠르게 바뀌는 개발 환경에서 반복 실측과 맞물리기 좋습니다. OpenAI 릴리스 노트를 따라 Realtime 경로가 바뀔 때마다 로그 한 줄씩만 업데이트하는 습관을 들이면 유지비가 크게 줄어듭니다.

설치와 프로필 반영 절차는 문서·튜토리얼을 참고하시고, 분할을 적용할 준비가 되었다면 Clash를 무료로 다운로드한 뒤 본문 예시를 바탕으로 proxy-groups와 rules만 조정해 보시길 바랍니다. Realtime WebSocket이 안정되면 음성 에이전트·실시간 통역 같은 다음 단계 실험도 한결 덜 끊깁니다.