고급 설정
예상 읽기 시간 19분

TUN 모드와 시스템 프록시 중 무엇을 선택할까: 두 트래픽 가로채기 방식의 원리 비교

Clash를 통해 ChatGPT를 사용할 때 연결 시간 초과, 무한 로딩, 느린 응답이 발생하나요? 시스템 프록시와 작동 모드, 프록시 노드, 규칙 적용 상태를 순서대로 점검하고 노드 변경, 규칙 수정, TUN 모드 설정으로 문제를 해결하는 방법을 안내합니다.

먼저 원인 범위 좁히기: 노드, 규칙, 모드 중 어디에서 멈추는가

Clash에서 ChatGPT가 열리지 않고 연결 시간이 초과되는 현상은 단순히 “노드가 느리다”는 한 가지 원인으로 설명되지 않습니다. 선택한 노드가 해외 서비스에 연결하지 못할 수도 있고, ChatGPT 도메인이 DIRECT 또는 REJECT로 처리될 수도 있습니다. 또한 브라우저가 시스템 프록시를 사용하지 않거나, TUN 모드와 기존 VPN의 라우팅이 충돌해 요청이 Clash 코어에 도달하지 않는 경우도 있습니다.

먼저 문제를 재현할 때 테스트 조건을 고정하세요. 같은 브라우저의 시크릿 창에서 https://chatgpt.com을 열고, Clash의 현재 모드와 정책 그룹, 실제 선택된 노드 이름을 기록합니다. 일반 웹사이트도 함께 열어 ChatGPT만 실패하는지, 모든 HTTPS 사이트가 실패하는지 비교하면 원인 분류가 빨라집니다. ChatGPT만 시간 초과되면 도메인 규칙이나 노드의 목적지 연결을 우선 확인하고, 모든 사이트가 실패하면 로컬 포트와 프록시 모드를 먼저 확인해야 합니다.

증상 가능성이 높은 원인 우선 확인할 항목
ChatGPT만 계속 로딩됨 도메인 규칙, 노드 지역, 정책 그룹 선택 로그의 매칭 규칙과 실제 출구 노드
ChatGPT와 일반 사이트 모두 실패 시스템 프록시, 로컬 포트, 코어 실행 상태 mixed-port, 클라이언트 실행 로그
첫 화면은 열리지만 로그인 또는 대화가 멈춤 관련 API·정적 리소스의 규칙 불일치, 연결 재설정 chatgpt.com, openai.com 요청 로그
브라우저만 되고 데스크톱 앱은 실패 앱이 시스템 프록시를 읽지 않음 앱별 프록시 지원 여부 또는 TUN 모드
노드를 바꾸면 잠깐 되다가 다시 실패 노드 품질 변동, 자동 그룹의 잦은 전환 url-test 간격과 현재 노드 지연·연결 상태

노드와 정책 그룹부터 확인하기

ChatGPT 접속 문제를 해결할 때 가장 먼저 할 일은 정책 그룹에서 실제로 어떤 노드가 선택되어 있는지 확인하는 것입니다. 클라이언트 화면에 “프록시 사용 중”이라고 표시되어도 최종 출구가 사용자가 생각한 노드와 다를 수 있습니다. 예를 들어 전역 모드는 켜져 있지만 ChatGPT 도메인 규칙이 별도의 그룹을 사용하거나, 해당 그룹이 DIRECT를 포함하고 있을 수 있습니다.

Clash Verge, Clash Verge Rev 또는 Mihomo 기반 클라이언트에서는 보통 「프로xies」 또는 「정책」 화면에서 현재 그룹의 선택 상태를 확인할 수 있습니다. ChatGPT 관련 요청을 테스트할 때는 자동 선택 그룹보다 먼저 특정 노드를 수동으로 선택해 보세요. 수동 노드에서 정상 접속되고 자동 그룹에서만 실패한다면 규칙 자체보다 url-test, fallback 또는 노드 상태 판단이 원인일 가능성이 높습니다.

자동 그룹을 사용한다면 측정 결과의 의미도 구분해야 합니다. url-test가 낮은 지연 시간을 기록했다고 해서 로그인, 스트리밍 응답, 긴 HTTPS 연결까지 모두 안정적이라는 뜻은 아닙니다. 테스트 주소가 204 응답을 빠르게 반환해도 실제 서비스로 가는 경로에서 TLS 협상이나 장시간 연결이 끊길 수 있습니다. ChatGPT의 응답이 중간에 멈추는 경우에는 지연 시간 숫자보다 연결 유지 여부를 더 중요하게 봐야 합니다.

라우팅 규칙과 DNS 확인: DIRECT로 빠지는 요청 찾기

ChatGPT는 한 개의 주소만 호출하는 단순한 웹페이지가 아닙니다. 기본 웹 화면, 로그인 흐름, 정적 리소스, API 요청이 여러 도메인과 HTTPS 연결을 사용할 수 있습니다. 따라서 chatgpt.com 하나만 프록시 그룹에 넣고 나머지 관련 도메인을 직접 연결하면 첫 화면은 보이지만 로그인, 대화 전송 또는 리소스 로딩이 실패할 수 있습니다.

먼저 로그 레벨을 잠시 debug로 올리고 문제를 한 번만 재현하세요. 로그에서 chatgpt.com, openai.com 및 관련 요청이 어떤 규칙에 매칭되고 어떤 정책을 사용하는지 확인합니다. 표시 형식은 코어 버전에 따라 다르지만 다음과 같은 흐름을 찾을 수 있습니다.

[TCP] 127.0.0.1:52314 --> chatgpt.com:443 match DomainSuffix(chatgpt.com) using PROXY[stable-01]
[TCP] 127.0.0.1:52318 --> api.openai.com:443 match FINAL using DIRECT

첫 번째 줄처럼 ChatGPT 요청이 원하는 프록시 그룹으로 들어갔다면 해당 요청의 규칙 경로는 일단 정상입니다. 두 번째 줄처럼 관련 요청이 FINAL과 DIRECT로 처리된다면 최종 규칙 또는 도메인 규칙을 다시 검토해야 합니다. 규칙은 위에서 아래로 평가되므로 너무 넓은 DOMAIN-SUFFIX,openai.com,DIRECT가 앞에 있으면 뒤에서 추가한 프록시 규칙은 실행되지 않습니다.

설정을 직접 관리한다면 서비스에 필요한 도메인을 무조건 과도하게 추가하기보다 로그에 실제로 나타난 도메인을 기준으로 좁게 수정하세요. 일반적인 형태는 다음과 같습니다. 사용 중인 코어가 규칙 세트와 YAML 문법을 지원하는지 먼저 확인하고, 기존 규칙의 순서를 반드시 함께 살펴보세요.

rules:
  - DOMAIN-SUFFIX,chatgpt.com,ChatGPT
  - DOMAIN-SUFFIX,openai.com,ChatGPT
  - MATCH,PROXY

DNS도 함께 확인해야 합니다. 로컬 DNS가 도메인을 잘못 해석하거나, DNS 요청은 프록시를 통과하지만 실제 연결은 다른 경로로 나가면 간헐적인 시간 초과가 발생할 수 있습니다. 설정을 크게 바꾸기 전에 클라이언트의 DNS 모드, Fake IP 사용 여부, 운영체제의 다른 VPN 또는 보안 프로그램이 DNS를 가로채는지 확인하세요. 문제 원인을 분리하는 단계에서는 기존 DNS 설정을 모두 바꾸기보다 한 번에 하나의 항목만 변경하는 편이 안전합니다.

직접 따라하는 점검 순서

다음 순서는 설정을 무작정 초기화하지 않고, 약 10분 안에 노드·규칙·프록시 모드를 분리해 확인하기 위한 절차입니다. 각 단계의 결과를 메모하면 이전 설정으로 되돌리기도 쉽습니다.

  1. Clash 클라이언트에서 코어가 실행 중인지 확인하고, 현재 코어 버전과 설정 파일이 정상적으로 로드되었는지 확인합니다.
  2. 정책 그룹에서 자동 선택을 잠시 해제한 뒤, 연결 상태가 안정적인 특정 노드를 수동으로 선택합니다.
  3. 브라우저의 기존 ChatGPT 탭을 닫고 시크릿 창을 열어 https://chatgpt.com에 접속합니다.
  4. Clash 로그에서 chatgpt.com 요청이 발생했는지, 최종 정책이 DIRECT인지 프록시 그룹인지 확인합니다.
  5. ChatGPT만 실패하면 해당 도메인 규칙과 규칙 순서를 확인하고, 일반 사이트도 실패하면 127.0.0.1 로컬 포트부터 점검합니다.
  6. 시스템 프록시를 끈 상태와 켠 상태를 각각 테스트합니다. 두 상태의 결과가 같다면 브라우저가 해당 프록시 설정을 읽지 않을 가능성이 있습니다.
  7. 수동 노드에서 성공한 뒤에만 자동 그룹으로 되돌립니다. 자동 그룹으로 바꾼 직후 다시 실패하면 그룹의 노드 상태 검사나 전환 조건을 조정합니다.

명령줄에서 로컬 프록시가 응답하는지도 확인할 수 있습니다. 아래 명령은 브라우저의 모든 동작을 재현하지는 않지만, Clash의 로컬 HTTP 프록시가 요청을 받고 HTTPS 대상에 연결하는지 확인하는 데 유용합니다.

curl -I -x http://127.0.0.1:7890 https://chatgpt.com
curl -I -x http://127.0.0.1:7890 https://example.com

두 명령 모두 로컬 연결 오류를 반환하면 포트 번호가 틀렸거나 코어가 해당 포트에서 수신하지 않는 것입니다. example.com은 성공하지만 ChatGPT만 시간 초과되면 로컬 프록시 자체보다 규칙, 노드 출구 또는 대상 네트워크 경로에 집중하세요. 단, 일부 환경에서는 대상 사이트가 HEAD 요청을 다르게 처리할 수 있으므로 명령 결과만으로 서비스 전체의 정상 여부를 단정하지는 마세요.

시스템 프록시와 TUN 모드의 선택

브라우저에서만 ChatGPT를 사용한다면 우선 시스템 프록시를 선택하는 것이 문제를 분리하기 쉽습니다. Chrome, Edge, Safari 등은 운영체제 네트워크 설정을 따르는 경우가 많지만, 모든 데스크톱 앱이 시스템 프록시를 읽는 것은 아닙니다. Clash의 mixed-port: 7890을 사용하는 경우 운영체제 프록시 주소가 127.0.0.1, 포트가 7890인지 확인하세요. 실제 포트는 클라이언트 화면에 표시된 값을 우선해야 합니다.

Windows에서는 「설정」→「네트워크 및 인터넷」→「프록시」에서 수동 프록시 항목을 확인하고, macOS에서는 「시스템 설정」→「네트워크」→현재 연결→「세부사항」→「프록시」에서 HTTP·HTTPS 프록시 값을 확인합니다. ClashX 계열 클라이언트는 메뉴 막대의 시스템 프록시 메뉴가 활성화되어 있는지도 확인해야 합니다.

시스템 프록시가 켜져 있는데도 ChatGPT 앱이나 특정 프로그램만 실패한다면 TUN 모드를 검토할 수 있습니다. TUN은 애플리케이션이 프록시를 명시적으로 지원하지 않아도 IP 계층에서 트래픽을 Clash 코어로 전달하는 방식입니다. 그러나 관리자 권한, 가상 네트워크 인터페이스, DNS 하이재킹이 함께 작동하므로 기존 VPN·기업 보안 프로그램·가상 머신 네트워크와 충돌할 수 있습니다.

상황 먼저 시도할 방식 주의할 점
브라우저에서 ChatGPT만 사용 시스템 프록시 브라우저가 실제로 운영체제 프록시를 읽는지 확인
ChatGPT 데스크톱 앱 또는 프록시 미지원 앱 TUN 모드 권한, DNS, 다른 VPN과의 라우팅 충돌 확인
시스템 프록시와 TUN을 동시에 사용 문제 분리 후 하나씩 사용 이중 처리로 루프나 예측하기 어려운 규칙 매칭이 생길 수 있음

시간 초과가 계속될 때의 고급 조정

기본 노드 교체와 규칙 확인 후에도 문제가 남는다면 연결 시간 초과가 어느 단계에서 발생하는지 로그를 다시 확인하세요. DNS 조회에서 멈추는지, 원격 노드와의 TCP 연결에서 멈추는지, HTTPS의 TLS 핸드셰이크 이후 응답이 없는지에 따라 조정 항목이 달라집니다. 모든 값을 한꺼번에 변경하면 무엇이 효과가 있었는지 알 수 없으므로 변경 후 한 번씩 재현하는 방식이 좋습니다.

자동 그룹을 사용하는 경우에는 interval과 tolerance도 살펴보세요. 예를 들어 60초마다 측정하고 허용 오차를 0으로 두면 작은 지연 차이에도 노드가 자주 바뀔 수 있습니다. ChatGPT처럼 로그인 세션과 긴 응답 연결을 사용하는 서비스에서는 잦은 전환보다 안정성이 중요하므로, 우선 interval: 300과 적당한 tolerance를 사용해 변동을 줄이는 편이 낫습니다. 실제 지원 필드는 Clash 코어 버전에 따라 다르므로 설정 오류가 발생하면 해당 필드를 제거하고 기본 그룹부터 검증하세요.

마지막으로 debug 로그를 계속 켜 두지 마세요. 문제 재현이 끝나면 log-level: info로 복원하고, 임시로 추가한 규칙과 DNS 설정을 정리합니다. 정상 접속을 확인한 뒤에는 수동 노드, 자동 그룹, TUN 모드를 각각 하나씩 되돌려 어느 설정이 실제로 영향을 주었는지 확인하면 다음 장애에서도 빠르게 대응할 수 있습니다.

Clash 다운로드