1. 흔한 증상: “채팅·계정은 되는데 Sora·동영상만 끊긴다”

같은 세션에서 채팅·썸네일·UI는 나오는데, Sora 뷰·동영상 재생·공유 링크만 스피너·버퍼·초 단위로 멈추면, 오류가 없어도 트래픽이 여러 FQDN으로 쪼개진 전형을 먼저 의심할 수 있습니다. chat.openai.com·WebSocket·REST API는 움직이는데, oai.com 호스트·미디어 배치·HLS .m3u8·.ts·fMP4 조각이 다른 노드·다른 홉을 타는 식이 대표적입니다. 개발자 도구 네트워크에 빨간 요청이 있으면 TLS·차단을, 없고 재생만 느리면 다른 IP 대역·다른 정책으로의 섞임을 봅니다.

Clash를 켰을 때만 악화한다면, NO_PROXY·시스템 프록시·확장과의 중복을 먼저 배제하고, 같은 프로필이 콘솔·curl에서도 일관한지 확인해 재현을 고정하십시오. 모바일 앱·특수 뷰어는 인증·certificate pinning·DoH가 겹쳐 원인이 섞일 수 있으니, PC 브라우저로 직선 경로를 먼저 잡는 편이 좋습니다.

2. oai.com·openai.com·HLS/미디어가 “한 덩어리”가 아닌 이유

OpenAI 제품은 2025–2026년에도 UI·빌링·developer API·스트리밍 엔드포인트·대용량 미디어를 한 도메인에 몰지 않는 편이고, 엣지·캐시·지역·객체·세그 단위로 이름이 쪼개집니다. oai.com 계열은 랜딩·짧은 비디오 경로에 노출될 수 있고, api·platform·chat 류는 openai.com 쪽, 실제 바이트 전송은 CDN·스토리지 벤더 호스트로 뻗는 경우가 많습니다. 구독 룰셋이 openai 일부만 잡고 나머지는 MATCH 뒤 DIRECT로 떨어지는 순간, 인증은 한 출구·세그는 다른 출구로 가며 세션·레이트·지연 체감이 틀어집니다. “API만 맞췄다”로 끝나지 않는 이유이며, 연결 로그에 찍힌 FQDN이 가장 믿을 만한 기준입니다.

또 DNS 응답이 지역·시간·캐시에 따라 달리면, 같은 rules를 썼는데 어제는 괜찮고 오늘만 어긋나는 느낌이 남을 수 있습니다. “openai만 덮어쓴 PROXY 한 줄”은 부작용과 지연을 키우기 쉬우므로, 로그로 확인된 이름만 DOMAIN-SUFFIX·DOMAIN-KEYWORD에 얹는 편이 안전합니다. (룰 예시 주석은 영어로 씁니다.)

3. DNS: fake-ip, redir-host, oai/미디어 질의

Mihomo·Clash Meta는 로컬 DNS를 중계하며 fake-ip 풀에 매핑하는 모드가 흔합니다. 짧은 TTL·빈번한 재조회가 스트리밍 클라에서는 DNS 한 번 어긋나도 세그 재시도 폭이 커질 수 있고, fake-ip와 실 IP가 섞이면 TLS SNI·검증 대상이 흐려집니다. 시도 순서는 (1) 클라이언트 로그의 query·응답 서버가 의도와 같은지, (2) redir-host 계열로 바꿔 비교, (3) fake-ip 범위·nameserver·fallback을 한꺼번에 뒤집지 말고 변수를 쪼개기, 입니다. DoH 구독과 OS 수동 DNS를 동시에 갈아엎으면 원인이 섞입니다. TUN 모드와 시스템 DNS 캡처 관계는 동일 프로필에서 함께 봅니다.

DNS만 맞췄는데 세그·초 단위 스톨이 남으면 다음 절 rules·정책 그룹으로 넘어갑니다. 로그에 oai·미디어 호스트가 아예 없다면, 애초에 트래픽이 Clash를 안 탄 경로 문제이므로, 기본 경로·분기 앱·킬 스위치를 같이 봅니다.

4. Mihomo `rules` 샘플: oai, openai, media, HLS

아래는 샘플이며, 운영 프로필의 프록시 그룹 이름·최종 MATCH 끝과 맞출 필요가 있습니다. 구독 룰 뒤에, 로그로 빠진 FQDN을 덧붙이는 흐름이 안전합니다.

# OpenAI / oai / media + API — adjust PROXY; verify real hostnames in logs
rules:
  - DOMAIN-SUFFIX,openai.com,PROXY
  - DOMAIN-SUFFIX,oaistatic.com,PROXY
  - DOMAIN-SUFFIX,oaiusercontent.com,PROXY
  - DOMAIN-SUFFIX,oai.com,PROXY
  - DOMAIN-SUFFIX,chatgpt.com,PROXY
  - DOMAIN-KEYWORD,openai,PROXY
  - DOMAIN-KEYWORD,oai,PROXY

실제 환경에는 akamai·cloudfront·gstatic 풍 엣지가 섞이며, “무조건 PROXY”가 항상 이득은 아닙니다. 지연·지역·노드 품질에 따라 특정 CDN은 DIRECT가 낫다면, 로그에 찍힌 그 FQDN 줄만 조정하십시오. 대규모 IP 대역 통짜 규칙은 다른 서비스까지 끌고 와 부작용이 날 수 있습니다. 채팅 전용 ChatGPT 가이드·Perplexity 글과 도메인 축이 다릅니다—비디오 점검을 우선하십시오.

5. 정책 그룹, 노드, 대역: 버퍼 vs. 지연

지연이 낮은 노드가 대용량 마이크로세그에는 불안정할 수 있고, CPU가 넉넉해도 TLS 핸드셰이크만 빨라 실제 처리량이 낮을 수도 있습니다. “글로벌 자동”으로 잠깐 돌렸을 때 재생이 한 축에 수렴하는지, 짧은 A/B로 노드 문제와 룰 누락을 갈라볼 수 있습니다. UDP는 비디오에 드문 편이지만, WebRTC·실시간 채널이 끼면 TUN 아래 UDP 행선지를 따로 봅니다. Grok·Gemini 글이 다루는 호스트는 oai·미디어 세트와 다릅니다.

rate limit·429·짧은 백오프가 로그에 찍히면, 같은 IP 대역에 다중 탭·여러 기기가 겹쳤는지, 다운로드 매니저·다른 자동 트래픽이 같은 출구에 붙었는지 봅니다. Clash는 경로 정리 도구이지, 쿼터를 늘려 주지는 않습니다.

6. TUN, 브라우저, UWP, 분기

Windows 일부 빌드·UWP·앱 컨테이너는 시스템 프록시를 달리 읽을 수 있고, Edge·Chrome 프로필·SwitchyOmega 유무에 따라 실제 흐름이 갈립니다. TUN 모드는 캡처 범위가 넓지만, 로컬 루프·LAN 관리 UI·사내망과 겹치면 예외 룰이 필요합니다. “브라우저만 프록시”와 “전체 OS TUN”을 번갈아 가며 세그 URL이 Clash 로그에 뜨는지 확인하십시오. 로그 자체가 없으면 규칙 이전 계층의 문제일 가능성이 큽니다.

7. 검증 순서(요약): 로그 → DNS → 룰 → 노드

권하는 순서는 (1) 같은 기기·같은 프로필로 채팅만 먼저 안정한지, (2) 재생 중 연결 패널에 oai·openai·미디어 호스트가 한 정책에 가깝게 모이는지, (3) DNS 질의 경로가 일관한지, (4) rules 우선순위에 누락이 없는지, (5) 노드 대역폭·지터입니다. 슬라이더를 한 번에 여러 개 돌리지 말고, 한 변수씩 줄입니다. 트러블슈팅의 구독·포트도 함께 봅니다. external-controller를 LAN에 둔 경우 토큰 노출에 주의하십시오—LAN 글의 allow-lan·방화벽 절을 참고합니다.

OpenAI 이용 약관·콘텐츠 정책·빌링·쿼터·퍼블릭 공유 조건은 2026년에도 수시로 바뀔 수 있습니다. 이 글은 기술 경로를 정리하는 참고이며, 권한·지역을 의도적으로 바꾸는 우회는 약관·법 쟁점에 들 수 있습니다. 최종 판단은 이용자 책임이며, 회사·학교 망·퍼블릭 Wi-Fi 정책도 별도로 확인하십시오.

9. 정리

Sora·OpenAI 비디오는 chat·API·oai·CDN·HLS 세그가 한 이름에 몰리지 않는 전형이 많고, Clash 뒤에서는 DIRECT·프록시 불일치가 버퍼·로딩 스톨로 드러납니다. 연결 로그에 찍힌 FQDN을 기준으로 DNS·rules·정책 그룹을 한 축에 가깝게 맞추고, 노드·대역폭을 따로 검증하는 절차가 재현성이 가장 큽니다. Codex 콘솔·채팅 전반 글과 겹치지 않게, 2026년 기준 비디오·oai·미디어 CDN만 떼어 읽으면 다른 AI 서비스 트러블슈에도 같은 뼈대를 그대로 이어 쓸 수 있습니다. 클라이언트는 공식 채널을 이용하십시오.→ Clash를 무료로 내려받고 oai·미디어·API 호스트를 같은 정책 축에 맞춰 보십시오