이 글이 맞는 증상
Sora 2 중국 사용법을 찾는 분들은 대개 계정과 기기 자체에는 문제가 없는데, 중국 내 네트워크에서 Sora 2 페이지가 열리지 않거나 로그인 화면이 반복되고, 영상 생성 요청을 보낸 뒤 작업이 오래 멈추는 상황을 겪습니다. 짧은 웹페이지는 표시되지만 영상 생성·미리보기·다운로드처럼 연결 시간이 긴 작업에서 실패한다면 단순한 브라우저 캐시보다 접속 경로, DNS, 프록시 규칙, 노드 안정성을 함께 점검해야 합니다.
이 글에서는 Clash Verge Rev와 Mihomo 계열 클라이언트를 기준으로 Sora 2 관련 트래픽을 프록시로 분기하는 흐름을 설명합니다. 특정 구독 업체나 특정 노드를 무조건 추천하지 않고, 구독 프로필을 추가한 뒤 실제 로그에서 어떤 호스트가 연결되는지 확인하고, 필요한 범위에만 규칙을 적용하는 방식입니다. Sora 2의 제공 국가, 계정 조건, OpenAI 서비스 정책은 시점과 지역에 따라 달라질 수 있으므로, 네트워크 설정을 바꾸더라도 공식 이용 조건과 현지 법규를 먼저 확인하세요.
Sora 2 접속에서 Clash가 하는 일
Clash는 Sora 2 계정이나 영상 생성 권한을 만들어 주는 도구가 아닙니다. 사용 중인 애플리케이션이 서버에 연결할 때 어느 DNS와 어느 출구 노드를 사용할지를 결정하는 로컬 프록시 클라이언트에 가깝습니다. 따라서 계정이 지원되지 않거나 서비스 측에서 생성 요청을 거절하는 문제는 Clash 설정만으로 해결되지 않습니다. 반대로 서비스 페이지가 지역 네트워크에서 제대로 로드되지 않고 로그인·생성 API가 모두 타임아웃으로 끝난다면, 올바른 프록시 경로를 지정하는 것이 첫 번째 점검 대상입니다.
웹 브라우저에서 보이는 주소 하나만 프록시로 보내면 항상 충분한 것은 아닙니다. 메인 페이지, 로그인 인증, 정적 파일, 작업 상태 확인, 영상 파일 전송이 서로 다른 호스트를 사용할 수 있기 때문입니다. 실제 호스트는 클라이언트 버전과 서비스 구조에 따라 변할 수 있으므로, 오래된 블로그의 도메인 목록을 그대로 복사하기보다 Clash 연결 로그에서 Sora 2를 열고 생성 버튼을 누르는 동안 기록되는 Host를 확인하는 편이 정확합니다.
| 점검 대상 | 확인할 내용 | 문제가 생길 때 보이는 증상 |
|---|---|---|
| DNS | 도메인이 정상적으로 해석되고 응답이 프록시 경로와 일치하는지 | 페이지가 오래 기다린 뒤 열리거나 인증 주소를 찾지 못함 |
| 인증 | 로그인·OAuth 관련 요청이 같은 정책 그룹을 타는지 | 로그인 후 다시 로그인 화면으로 돌아감 |
| API·스트리밍 | 생성 요청과 작업 상태 확인 요청이 DIRECT로 빠지지 않는지 | 생성 버튼은 눌리지만 작업이 멈추거나 타임아웃 발생 |
| 미디어 전송 | 미리보기·다운로드 호스트가 별도 규칙으로 누락되지 않았는지 | 완성된 영상이 보이지 않거나 다운로드가 중단됨 |
설정 전 준비: 계정·클라이언트·프로필 확인
먼저 Sora 2를 이용할 계정이 실제로 해당 기능에 접근할 수 있는지 확인합니다. 다른 네트워크에서 공식 페이지가 열리고 계정 대시보드까지 정상적으로 표시되는지 확인해야 합니다. 프록시를 켠 뒤에도 403, 429, 401 같은 HTTP 오류가 나온다면 네트워크 경로와 별개로 지역 지원 범위, 인증 토큰, 요금제, 호출 한도 문제가 원인일 수 있습니다. 이런 응답을 단순히 노드를 계속 바꾸는 문제로 오해하면 계정 보호 시스템을 자극할 수 있습니다.
데스크톱에서는 Clash Verge Rev 또는 사용 중인 Mihomo 호환 클라이언트를 최신 안정 버전으로 준비합니다. 앱을 여러 개 동시에 실행하면 시스템 프록시 포트와 DNS 처리가 충돌할 수 있으므로, 테스트할 때는 다른 VPN·프록시 확장·가상 네트워크 도구를 잠시 끄는 것이 좋습니다. 이미 프로필이 있다면 업데이트 후 활성 프로필이 바뀌지 않았는지, 코어가 재시작 루프에 빠지지 않았는지 먼저 봅니다.
구독 URL을 가져올 때는 제공자가 안내한 공식 경로를 이용하고, YAML을 메신저나 출처가 불분명한 게시물에서 내려받지 마세요. 프로필에는 서버 주소와 인증 정보가 포함될 수 있으므로 공개 저장소에 올리거나 다른 사람에게 그대로 전달하지 않는 것이 안전합니다. 가져오기 전에 만료일, 기기 수 제한, 트래픽 제한, 지원 코어를 확인하면 이후의 연결 실패를 줄일 수 있습니다.
1단계: Clash에 프로필을 추가하고 기본 연결 만들기
Clash Verge Rev에서 프로필 또는 Profiles 화면을 열고 구독 URL을 입력합니다. 원격 프로필을 추가한 뒤 다운로드가 끝나면 해당 프로필을 선택해 활성화하고, 코어가 정상적으로 실행되는지 확인합니다. 프로필 이름이 비슷한 항목이 여러 개라면 만료일이나 업데이트 시간을 기준으로 최신 항목을 고르되, 업데이트 직후 규칙 세트가 바뀌었을 가능성도 염두에 둡니다.
다음으로 프록시 모드를 확인합니다. Rule 모드는 도메인과 IP 규칙에 따라 트래픽을 나누므로 일상적인 사용에 적합합니다. Global 모드는 모든 연결을 선택한 노드로 보내 테스트하기에는 편하지만, Sora 2 외의 연결까지 같은 노드에 몰립니다. 먼저 글로벌 모드에서 서비스 페이지가 열리는지 짧게 확인한 다음, 규칙 모드로 돌아가 실제 Sora 관련 호스트가 어느 그룹으로 가는지 비교하면 원인 분리가 쉽습니다.
Clash의 로그 화면을 열어 둔 상태에서 브라우저를 새로 시작하고 로그인 페이지, 새로 고침, 영상 생성 화면을 순서대로 실행합니다. 로그에서 요청이 DIRECT로 표시되면 해당 호스트가 프록시를 타지 않는다는 뜻이고, REJECT라면 차단 규칙이나 광고·보안 필터가 요청을 거부한 것입니다. 모든 요청이 같은 노드로 가야 한다는 뜻은 아니지만, 인증과 생성 작업이 서로 다른 경로로 나뉘면 세션이 불안정해질 수 있습니다.
규칙을 직접 추가할 때는 지나치게 넓은 DOMAIN-KEYWORD를 피합니다. 예를 들어 openai라는 문자열을 포함하는 모든 도메인을 한 그룹으로 보내면 관련 없는 서비스나 다운로드 주소까지 영향을 받을 수 있습니다. 로그에서 확인한 정확한 호스트에는 DOMAIN 또는 필요한 경우 제한적인 DOMAIN-SUFFIX를 사용하고, 마지막에는 기존 규칙보다 먼저 평가되도록 위치를 확인해야 합니다.
2단계: Sora 2 관련 트래픽을 규칙으로 분기하기
가장 관리하기 쉬운 구성은 Sora 2 접속에 필요한 호스트를 하나의 프록시 그룹에 연결하고, 나머지 트래픽은 기존 정책을 유지하는 방식입니다. 그룹 이름은 Sora-Proxy처럼 알아보기 쉽게 정하되, 실제 서버 이름이 아니라 정책 그룹이라는 점을 기억하세요. 여러 노드가 들어 있는 그룹이라면 자동 선택 기능을 사용하더라도 테스트 초반에는 특정 노드를 고정해 로그를 비교하는 편이 좋습니다.
로그에서 로그인 관련 요청과 생성 관련 요청이 서로 다른 도메인으로 나타날 수 있습니다. 인증 호스트만 프록시로 보내면 로그인은 성공하지만 생성 API가 실패할 수 있고, 반대로 생성 API만 분기하면 토큰 갱신이 끊겨 작업이 중간에 멈출 수 있습니다. 따라서 다음 순서로 확인합니다.
- 로그인 페이지를 새로 열고 인증 호스트가 의도한 프록시 그룹에 매칭되는지 확인합니다.
- Sora 2 작업 화면을 열고 정적 파일과 API 요청이 DIRECT로 빠지지 않는지 살펴봅니다.
- 짧은 테스트 작업을 실행해 생성 요청, 작업 상태 확인, 미리보기 요청의 경로를 비교합니다.
- 완성된 파일을 내려받을 때 새 호스트가 등장하는지 확인하고 필요한 경우에만 규칙을 보완합니다.
규칙을 수정한 뒤에는 반드시 저장·적용하고 코어를 재시작합니다. 화면에 규칙이 보인다는 것만으로 실제 실행 중인 코어에 반영되었다고 단정할 수 없습니다. 특히 원격 프로필을 다시 업데이트하면 직접 추가한 규칙이 사라지거나 우선순위가 바뀔 수 있으므로, 커스텀 오버라이드 기능이 있다면 그곳에 별도로 보관합니다.
처음부터 모든 OpenAI 관련 주소를 한꺼번에 프록시로 묶는 것은 권장하지 않습니다. 범위를 넓히면 문제를 찾기 어려워지고, 불필요한 트래픽이 노드로 이동해 영상 생성 속도에도 영향을 줄 수 있습니다. Sora 2를 실행하는 동안 실제로 관찰된 호스트만 기록하고, 한 번에 한 규칙씩 추가한 뒤 결과를 확인하는 방식이 재현성과 유지보수 측면에서 유리합니다.
3단계: 안정적인 노드 고르는 기준
영상 생성은 단순한 웹페이지 접속보다 연결 시간이 길고 데이터 전송량도 많습니다. 그래서 핑이 가장 낮은 노드가 항상 가장 좋은 선택은 아닙니다. ICMP 핑은 짧은 패킷의 왕복 시간만 보여 주며, 실제 HTTPS 연결의 TLS 협상, HTTP/2 스트리밍, 장시간 유휴 연결 유지 능력까지 보장하지 않습니다. 노드를 비교할 때는 페이지 로딩 시간과 실제 테스트 작업의 완료 여부를 함께 기록해야 합니다.
| 지표 | 좋은 신호 | 주의할 신호 |
|---|---|---|
| 연결 지연 | 로그인과 작업 화면이 일정한 시간 안에 열림 | 첫 연결마다 지연 시간이 크게 달라짐 |
| 지속 연결 | 작업 상태가 끊기지 않고 완료까지 갱신됨 | 생성 중 연결 재설정이나 빈 응답 발생 |
| 처리량 | 미리보기와 파일 다운로드 속도가 일정함 | 초반만 빠르고 일정 시간이 지나면 급격히 느려짐 |
| 출구 일관성 | 같은 세션에서 출구 지역과 정책이 갑자기 변하지 않음 | 자동 선택이 짧은 시간마다 다른 노드로 이동함 |
자동 선택 그룹을 사용할 때는 지연 시간뿐 아니라 실패율과 최근 전환 기록을 함께 보세요. 영상 작업 중 노드가 바뀌면 세션 쿠키나 장시간 요청이 끊길 수 있습니다. 생성 시작부터 완료까지는 안정적인 단일 노드를 유지하고, 여러 노드를 번갈아 바꾸는 테스트는 작업이 끝난 후 별도로 진행하는 것이 안전합니다. 노드가 특정 서비스에서 차단된 것처럼 보여도 바로 계정을 여러 IP에서 반복 로그인하지 말고, 먼저 브라우저 세션과 Clash 로그를 정리한 뒤 한 노드에서 재현 여부를 확인하세요.
연결 실패를 단계별로 해결하는 방법
페이지가 아예 열리지 않을 때
먼저 브라우저 확장 프록시와 시스템 프록시가 동시에 켜져 있지 않은지 확인합니다. 이중 프록시는 DNS와 TLS 경로를 복잡하게 만들고, 한쪽이 연결을 닫았을 때 다른 쪽 로그에는 원인이 명확히 남지 않을 수 있습니다. Clash의 시스템 프록시를 켠 뒤 브라우저를 완전히 종료하고 다시 실행합니다. 그다음 DNS 모드와 연결 로그에서 도메인 해석 실패가 있는지 확인하세요.
로그인이 반복될 때
로그인 페이지와 인증 요청이 서로 다른 출구를 사용하면 보안 세션이 무효화될 수 있습니다. 인증 관련 호스트가 DIRECT로 빠지는지, 노드가 요청 사이에 자동 교체되는지 살펴봅니다. 브라우저 쿠키를 무작정 삭제하기 전에 시크릿 창에서 한 번 테스트하면 기존 세션 문제와 네트워크 경로 문제를 구분할 수 있습니다. 401이나 추가 인증 화면이 표시된다면 계정 인증 문제일 가능성이 있으므로 프록시 설정과 별도로 처리해야 합니다.
생성 작업이 멈추거나 실패할 때
생성 요청이 전송된 뒤 일정 시간 후 실패한다면 연결이 오래 유지되는지 확인합니다. Clash 로그에서 요청이 반복 재시도되는지, 특정 시점에 connection reset이나 timeout이 나타나는지 봅니다. 같은 노드에서 짧은 작업은 성공하고 긴 작업만 실패하면 노드 혼잡, 스트리밍 유지 능력, MTU 또는 일시적인 서비스 측 부하를 의심할 수 있습니다. 이 경우 규칙을 넓히기보다 다른 안정 노드로 한 번만 비교하고, 서비스 상태와 계정 한도도 함께 확인하세요.
영상은 완성됐지만 다운로드가 실패할 때
완성 알림과 실제 미디어 파일 전송이 별도 요청일 수 있습니다. 다운로드 버튼을 누르는 순간 로그에 새 호스트가 나타나는지 확인하고, 해당 주소가 프록시 그룹에서 누락되지 않았는지 봅니다. 파일 전송 중 브라우저를 닫거나 노드를 바꾸면 재개가 되지 않을 수 있으므로, 안정적인 연결을 유지한 상태에서 작은 파일로 먼저 테스트합니다. 회사·학교 네트워크의 보안 장비가 대용량 파일을 검사하는 경우에는 Clash 외부의 정책도 영향을 줄 수 있습니다.
보안과 유지 관리 체크리스트
프록시 프로필은 단순한 즐겨찾기 목록이 아니라 서버 주소, 인증 토큰, 규칙, DNS 정책을 포함하는 설정 파일입니다. 출처가 불명확한 프로필을 사용하면 Sora 2 접속 여부와 별개로 광고 주입, 악성 규칙, 트래픽 탈취 위험이 생길 수 있습니다. 구독 URL을 공개 게시판에 붙여 넣지 말고, 프로필을 공유해야 한다면 민감한 주소와 토큰을 제거한 예시 파일만 사용하세요.
Clash 코어와 클라이언트는 안정 버전을 우선하고, 업데이트 후에는 기존 규칙이 그대로 유지되는지 확인합니다. 프로필을 갱신하기 전 커스텀 규칙을 별도 파일이나 안전한 메모에 백업하면 갑작스러운 덮어쓰기에 대비할 수 있습니다. 또한 Sora 2를 사용하지 않을 때는 시스템 프록시와 TUN을 끄는 습관을 들이면 국내 서비스의 접속 지연, 사내 시스템 오류, 배터리 사용량 증가를 줄일 수 있습니다.
개인정보 보호 측면에서도 프롬프트와 생성 결과의 전송 경로를 이해해야 합니다. 프록시는 전송 경로를 바꾸지만, 서비스 제공자가 요청을 처리하는 방식이나 계정에 저장하는 데이터 정책을 바꾸지는 않습니다. 민감한 얼굴 사진, 업무 문서, 고객 정보가 포함된 프롬프트는 회사 정책과 서비스 약관을 먼저 확인하고, 필요하다면 비식별화한 테스트 자료로 연결을 검증하세요.
마무리: 안정적인 설정의 기준
Sora 2 중국 접속을 안정화하는 핵심은 무작정 글로벌 모드를 켜는 것이 아니라, 계정 상태를 먼저 확인하고, 실제 로그에 나타난 인증·생성·미디어 호스트를 구분한 뒤, 안정적인 노드 하나와 명확한 규칙으로 경로를 고정하는 데 있습니다. 페이지가 열리는 것만으로 성공을 판단하지 말고 로그인 유지, 테스트 생성 완료, 미리보기 표시, 다운로드까지 한 사이클을 확인해야 합니다.
일부 간편 VPN이나 브라우저 전용 프록시는 설치가 쉽지만, 앱 외부의 생성 요청을 놓치거나 노드 전환과 DNS 동작을 세밀하게 확인하기 어렵고, 문제가 생겼을 때 어떤 요청이 실패했는지 보여 주지 않는 경우가 있습니다. 반면 Clash는 규칙 모드, 연결 로그, 노드 그룹, TUN·시스템 프록시 선택을 분리해 관리할 수 있어 Sora 2처럼 인증과 장시간 영상 작업이 함께 필요한 환경에서 원인을 좁히기 쉽습니다. 필요한 트래픽만 분기하면서 다른 서비스의 경로는 유지하고 싶다면, 이 글의 기준으로 자신의 기기와 공식 이용 조건에 맞는 설정을 구성해 보세요.