Clash
문제 해결 가이드

재현 가능한 기본 점검 기준 만들기

문제 해결의 첫 단계는 설정을 바꾸는 것이 아니라 장애 범위를 정하는 것입니다. 문제가 발생한 시간, 현재 네트워크 유형, 클라이언트 이름, 프록시 모드, 선택한 노드, 대상 웹사이트와 오류 원문을 먼저 기록하세요. 데스크톱에서는 시스템 프록시와 TUN 활성화 여부도 기록하고, 모바일에서는 VPN 표시가 나타났는지와 시스템이 앱의 백그라운드 활동을 제한하는지도 확인해야 합니다. “안 돼요”라고만 적으면 어떤 단계에서 해결됐는지 판단하기 어렵고, 일시적인 네트워크 흔들림과 안정적인 설정 오류도 구분할 수 없습니다.

네트워크 경로를 여섯 구간으로 나누기

하나의 연결은 보통 애플리케이션, 운영체제 프록시 또는 가상 네트워크 인터페이스, Clash 리스닝 포트, 규칙과 정책 그룹, 원격 노드, 대상 서비스의 순서로 진행됩니다. 어느 한 구간이라도 실패하면 브라우저에는 연결 시간 초과로만 보일 수 있습니다. 점검할 때는 가까운 구간부터 확인하세요. 클라이언트 프로세스가 실행 중인지, 포트가 리스닝 중인지, 설정이 정상적으로 로드됐는지, 정책 그룹에서 사용 가능한 노드를 선택했는지, 노드가 연결을 수립하는지, 대상 주소가 현재 출구에서 허용되는지 순서대로 살펴봅니다. 클라이언트, 구독과 DNS를 동시에 바꾸지 마세요. 여러 변수가 함께 바뀌면 판단 근거가 사라집니다.

먼저 시스템 프록시와 TUN을 끄고 브라우저에서 평소 접속 가능한 사이트에 직접 접속하세요. 직접 연결도 실패한다면 Clash를 수정하기 전에 Wi-Fi, 유선 연결, 게이트웨이, 인증 페이지 또는 시스템 DNS를 먼저 처리해야 합니다. 직접 연결이 정상이라면 클라이언트를 실행하되 아직 시스템 트래픽을 가로채지 말고, 로그에서 설정 로드가 완료되는지 확인하세요. 마지막으로 시스템 프록시 또는 TUN을 켜고 도메인 요청과 순수 IP 요청을 각각 테스트합니다. 도메인만 실패하고 IP는 연결되면 대개 DNS 문제입니다. 둘 다 실패하면 포트, 노드와 라우팅을 계속 확인하세요.

포트와 로그 증거 수집

일반적인 설정은 mixed, HTTP 또는 SOCKS 리스닝 포트를 엽니다. 구체적인 숫자는 현재 설정과 클라이언트 UI를 기준으로 해야 하며, 인터넷 예시만 보고 판단하면 안 됩니다. Windows에서는 PowerShell로 리스닝 상태를 확인하고, macOS와 Linux에서는 lsof를 사용할 수 있습니다. 명령 결과가 없으면 커널이 정상적으로 리스닝하지 못했거나 설정이 로드되지 않았거나, 포트를 다른 프로그램이 사용 중일 수 있습니다.

# Windows PowerShell: 7890을 UI에 표시된 포트로 바꾸세요
Get-NetTCPConnection -LocalPort 7890 -State Listen

# macOS / Linux
lsof -nP -iTCP:7890 -sTCP:LISTEN

# 로컬 HTTP 프록시를 통해 테스트 요청 보내기
curl -I --proxy http://127.0.0.1:7890 https://example.com

로그 수준은 먼저 info를 사용하는 것이 좋습니다. 설정 로드, 규칙 일치, DNS 조회와 연결 오류를 확인하기에 충분하면서 debug처럼 출력이 빠르게 쌓이지 않습니다. 단일 요청을 추적해야 할 때만 잠시 로그 수준을 높이고 재현이 끝나면 원래대로 돌리세요. 오류 발생 전후의 열 줄 남짓한 로그를 저장하는 것이 중요합니다. 마지막 한 줄만 캡처하지 마세요. 예를 들어 “연결 시간 초과” 전에 도메인 조회 실패, 정책 그룹 비어 있음 또는 호환되지 않는 설정 필드가 이미 나타났을 수 있습니다.

기본 점검이 끝나면 세 가지 질문에 답할 수 있어야 합니다. 클라이언트가 정상적으로 시작됐는가, 로컬 프록시가 독립적으로 요청을 완료할 수 있는가, 문제가 특정 노드나 특정 유형의 도메인에서만 발생하는가입니다. 여전히 답할 수 없다면 고급 파라미터로 넘어가지 말고 로그를 더 수집하세요. 반복해서 “업데이트”나 “복구”를 누르는 것보다 안정적인 증거 체인이 빠르고, 여러 클라이언트에서 같은 문제를 재현하기도 쉽습니다.

Clash를 켜면 인터넷이 완전히 끊김

이 증상은 시스템 프록시 또는 TUN을 켠 뒤 브라우저, 메신저와 앱 스토어가 동시에 연결을 잃고, 트래픽 가로채기를 끄면 네트워크가 복구되는 형태로 나타납니다. 먼저 노드가 반드시 고장 났다고 단정하지 마세요. 시스템 트래픽은 로컬 프록시로 전달됐지만 커널에 사용 가능한 출구가 없거나, 리스닝 포트가 일치하지 않거나, 규칙이 트래픽을 비어 있는 정책 그룹으로 보내도 같은 현상이 발생합니다. 먼저 로컬 프록시 경로가 성립하는지 입증한 뒤 시스템 트래픽 가로채기를 확인해야 합니다.

먼저 클라이언트 내부 상태 확인

설정 페이지에 현재 설정이 로드됐다고 표시되는지, 정책 그룹에 노드가 존재하는지, 활성 정책이 실제로 노드를 선택했는지 확인하세요. 일부 구독은 업데이트 후 정책 그룹 이름이 바뀌어 이전 선택 기록이 새 그룹과 연결되지 않습니다. UI는 규칙 모드로 보이지만 실제 그룹에는 유효한 대상이 없을 수도 있습니다. 다른 노드로 수동 전환해 지연 시간을 테스트하는 것은 초기 확인일 뿐입니다. 테스트 주소, 프로토콜과 실제 접속 경로가 다를 수 있으므로 지연 테스트 성공을 웹페이지 접속 가능과 동일하게 보면 안 됩니다.

이후 시스템 프록시를 끄고 클라이언트만 실행한 상태에서 curl로 로컬 프록시를 명시해 요청하세요. 명령이 성공하면 커널, 설정과 노드는 대체로 정상이며 문제는 시스템 프록시나 앱 측에 집중됩니다. 명령이 connection refused를 반환하면 UI 포트와 설정의 mixed-port, port가 일치하는지 확인하세요. timeout이면 노드를 계속 점검하고, proxy connect aborted 또는 설정 오류가 나타나면 시작 로그를 다시 확인합니다.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

# 시스템 프록시 설정에 의존하지 않고 로컬 프록시만 확인
curl -v --proxy http://127.0.0.1:7890 https://example.com

포트 충돌과 루프백 주소 확인

한 장치에서 두 프록시 클라이언트를 동시에 실행하면 나중에 시작한 커널이 포트를 바인딩하지 못할 수 있습니다. 대표적인 로그는 address already in use, bind failed 또는 listen error입니다. 다른 클라이언트를 종료한 뒤 다시 시작하세요. 함께 실행해야 한다면 각 인스턴스에 다른 포트를 할당합니다. 리스닝 주소를 임의로 LAN 주소로 바꾸지 마세요. 로컬에서 사용할 때는 루프백 리스닝을 유지하는 것이 우선입니다. LAN 장치에 프록시를 제공해야 할 때만 allow-lan을 켜고, 방화벽과 신뢰할 수 있는 네트워크 경계도 함께 확인하세요.

프록시를 명시한 요청은 성공하지만 모든 앱에서 인터넷이 되지 않는다면 시스템 프록시를 껐다가 다시 켜서 클라이언트가 운영체제 설정을 다시 기록하도록 하세요. 프록시 서버가 127.0.0.1을 가리키는지, 포트가 클라이언트와 일치하는지 확인합니다. PAC, 다른 VPN, 브라우저 확장 프로그램 또는 기업용 네트워크 도구를 사용한 적이 있다면 여러 설정이 서로 덮어쓸 수 있습니다. 브라우저가 독립 프록시를 설정한 경우 시스템 설정을 우회할 수도 있습니다. 이때는 브라우저 네트워크 설정을 일시적으로 기본값으로 되돌리고 하나의 트래픽 가로채기 방식만 남겨 테스트하세요.

TUN 모드의 추가 점검

TUN은 시스템 프록시보다 더 넓은 트래픽을 가로채므로 권한, 라우팅과 DNS 중 하나라도 제대로 작동하지 않으면 영향 범위가 커집니다. Windows에서는 서비스 권한과 가상 네트워크 인터페이스 상태를 확인하고, macOS에서는 시스템 확장 프로그램 또는 VPN 설정이 승인됐는지 확인하세요. Linux에서는 프로세스에 TUN 장치 생성과 라우팅 수정 권한이 있는지 점검합니다. 기본 라우트를 생성하는 VPN을 두 개 동시에 켜지 마세요. TUN을 끄고 시스템 프록시로 바꿨을 때 복구된다면 노드와 설정에는 문제가 없을 수 있으므로 가상 네트워크 인터페이스, 라우팅 테이블과 DNS 가로채기를 집중적으로 확인하세요.

규칙의 오판도 배제해야 합니다. 모드를 잠시 글로벌로 바꿔 짧게 한 번만 테스트하세요. 글로벌에서는 작동하지만 규칙 모드에서는 작동하지 않는다면 요청이 잘못된 정책 또는 DIRECT로 전달된 것입니다. 연결 로그에서 일치한 규칙을 확인하고 MATCH의 최종 정책, 규칙 세트 로드 성공 여부와 정책 그룹 존재 여부를 점검하세요. 테스트가 끝나면 규칙 모드로 되돌리고, 글로벌 프록시를 장기간 사용해 규칙 오류를 가리지 마세요.

복구 순서는 명확해야 합니다. 기본 네트워크가 정상인지 확인하고, 클라이언트가 설정을 로드했는지 확인한 다음, 로컬 포트가 리스닝하는지 확인하고, 프록시를 명시한 요청이 성공하는지 확인한 뒤 마지막으로 시스템 프록시 또는 TUN을 복구하세요. 각 단계가 성공한 뒤에만 다음 단계로 넘어갑니다. 클라이언트를 바꿔야 한다면 다운로드 페이지에서 플랫폼과 아키텍처를 확인하세요. 이전할 때는 구독 주소와 사용자 지정 규칙을 먼저 내보내고, 출처를 알 수 없는 설정 폴더 전체를 그대로 복사하지 마세요.

노드 시간 초과, 핸드셰이크 실패와 연결 재설정

노드 목록에 timeout이 표시된다는 것은 테스트 요청이 제한 시간 안에 완료되지 않았다는 뜻일 뿐, 로컬 클라이언트가 반드시 손상됐다는 의미는 아닙니다. 노드 서버에 도달할 수 없거나, 포트가 차단됐거나, 도메인이 잘못된 주소로 해석되거나, 시스템 시간이 어긋났거나, 프로토콜 파라미터가 일치하지 않거나, 테스트 URL이 현재 네트워크에서 작동하지 않는 것이 원인일 수 있습니다. 먼저 여러 노드를 비교하세요. 한 노드만 실패하면 노드 측 문제로 우선 판단하고, 같은 구독의 모든 노드가 실패하면 구독 내용, 로컬 네트워크와 프로토콜 지원을 확인합니다.

TCP, TLS와 애플리케이션 계층 오류 구분

로그의 i/o timeout은 보통 연결 또는 읽기·쓰기가 제한 시간을 초과했다는 뜻입니다. connection refused는 원격 주소에는 도달했지만 해당 포트에서 서비스가 실행되지 않는다는 의미이고, connection reset by peer는 연결 수립 후 원격 또는 중간 장비가 연결을 재설정했다는 뜻입니다. TLS handshake timeout은 핸드셰이크 단계의 문제를 가리키며, certificate 또는 server name 관련 오류는 시스템 시간, SNI, 인증서 이름과 구독 파라미터와 관련된 경우가 많습니다. 이 오류들을 모두 “노드 고장”으로 묶지 마세요. 단계마다 처리 방법이 다릅니다.

노드 주소가 도메인이라면 먼저 시스템 도구로 조회해 정상적인 A 또는 AAAA 레코드를 얻는지 확인하세요. 조회 결과가 자주 바뀌는 것은 반드시 이상이 아니지만, 결과가 전혀 없거나 예약 주소가 반환되거나 현재 네트워크에서 연결할 수 없는 IPv6 주소만 반환되면 DNS를 점검해야 합니다. 이어서 대상 포트의 TCP 연결성을 테스트하세요. 이 명령은 포트에 연결할 수 있는지만 보여 주며 프로토콜 인증까지 검증하지는 않습니다. 포트 연결은 성공하지만 클라이언트 핸드셰이크가 실패한다면 노드 파라미터를 계속 확인하세요.

# Windows PowerShell
Resolve-DnsName node.example.net
Test-NetConnection node.example.net -Port 443

# macOS / Linux
dig node.example.net A
dig node.example.net AAAA
nc -vz node.example.net 443

시간, 프로토콜과 커널 기능 확인

TLS는 올바른 시스템 시간에 의존합니다. 장치 시간이 크게 어긋나면 인증서가 아직 유효하지 않거나 이미 만료된 것으로 판단될 수 있습니다. 시스템 자동 시간 동기화를 켜고 연결을 다시 수립하세요. 그런 다음 구독의 프로토콜 유형이 현재 커널에서 지원되는지 확인합니다. 오래된 클라이언트나 유지 관리가 중단된 소프트웨어는 최신 필드를 인식하지 못해 설정 로드 실패, 노드 무시 또는 핸드셰이크 파라미터 누락으로 나타날 수 있습니다. 이런 경우 유지 관리되는 Clash Plus, Clash Verge Rev, FlClash 또는 mihomo 호환 클라이언트를 우선 사용하세요. 플랫폼별 선택은 다운로드 페이지에서 확인할 수 있습니다.

구독에서 생성된 비밀번호, UUID, 포트, 전송 방식, TLS 토글, server name 또는 네트워크 유형을 임의로 수정하지 마세요. 문자 하나만 달라도 TCP 연결은 성공할 수 있지만 인증 단계에서는 반드시 실패합니다. 구독 서비스에서 웹으로 노드 상세 정보를 제공한다면 클라이언트가 파싱한 필드와 하나씩 비교하세요. 구독 변환기가 필드를 누락했다는 사실을 확인한 경우에만 구독 형식을 바꾸거나 제공 업체에 문의해야 합니다.

같은 노드들이 가정용 인터넷에서는 모두 시간 초과되지만 모바일 핫스팟에서는 작동한다면 현재 접속 네트워크, 라우터 DNS, IPv6 경로 또는 포트 정책에 문제가 있을 가능성이 큽니다. 반대쪽 테스트도 유용합니다. 모바일 핫스팟에서는 실패하고 고정 인터넷에서는 작동한다면 모바일 네트워크의 IPv6, NAT 또는 절전 제한이 원인일 수 있습니다. 짧은 시간에 지연 테스트를 계속 대량으로 실행하지 마세요. 동시 요청이 많으면 원격 제한을 유발하고 로그도 읽기 어려워집니다. 두 개의 노드를 선택해 실제 웹페이지 요청을 하나씩 재현하세요.

테스트 주소와 실제 접속을 분리해 판단

지연 테스트는 보통 고정된 URL 하나에 접속합니다. 해당 주소에 연결할 수 없으면 노드가 시간 초과로 표시되지만 다른 웹사이트는 정상일 수 있습니다. 먼저 브라우저에서 실제 대상에 접속한 뒤 테스트 URL을 바꾸세요. 테스트 주소는 안정적이고 응답 본문이 작으며 HTTPS를 지원하는 사이트를 사용해야 합니다. 로그인이나 복잡한 리디렉션이 발생할 수 있는 페이지는 피하세요. URL Test 정책 그룹의 간격도 적절히 설정해야 합니다. 너무 짧으면 노드와 배터리 소모가 늘고, 너무 길면 출구 변경을 제때 발견하지 못합니다.

최종 판단은 교차 검증을 바탕으로 해야 합니다. 서로 다른 노드, 네트워크와 대상 주소로 최소 두 그룹의 비교 결과를 만드세요. 단일 노드만 실패하면 현재 정책에서 제외하고, 모든 노드가 한 네트워크에서만 실패하면 네트워크 경로를 처리하며, 모든 네트워크에서 실패하고 로그에 필드 미지원이 표시되면 클라이언트 호환성을 처리합니다. 이렇게 하면 원격 장애인데 로컬 소프트웨어를 반복해서 재설치하거나, 로컬 DNS 문제를 구독 전체의 장애로 오인하는 일을 피할 수 있습니다.

구독 가져오기, 업데이트와 설정 파싱 실패

구독 문제는 최소 네 가지로 나뉩니다. 링크 요청 불가, 서버가 로그인 페이지나 오류 페이지 반환, 클라이언트가 지원하지 않는 설정 형식 반환, 다운로드는 성공했지만 설정 파싱 실패입니다. UI의 “업데이트 실패”에는 원인이 자세히 표시되지 않는 경우가 많으므로 로그를 확인하거나 브라우저에서 응답을 검사해야 합니다. 계정 식별용 접근 정보가 포함될 수 있으므로 전체 구독 링크를 공개해서 붙여 넣지 마세요. 점검 화면에서는 링크 경로와 쿼리 파라미터를 가리세요.

링크 자체에 접속할 수 있는지 확인

먼저 복사 과정에서 공백, 줄바꿈 또는 중국어 구두점이 섞이지 않았는지 확인하세요. 일부 메신저는 긴 링크를 잘라내거나 마지막 문자를 텍스트 서식에 포함할 수 있습니다. 링크를 일반 텍스트 편집기에 붙여 넣고 프로토콜 시작부터 마지막까지 끊김 없이 완전한지 확인합니다. 브라우저에서 접속했을 때 로그인 페이지, 요금제 안내, CAPTCHA 또는 HTML 오류 페이지로 이동한다면 클라이언트가 이를 YAML로 파싱할 수 없습니다. 이때는 클라이언트 설정을 수정하지 말고 구독 서비스 페이지에서 링크를 다시 생성하세요.

브라우저에서 파일을 다운로드할 수 있다면 응답의 시작 부분을 확인하세요. Clash YAML의 일반적인 최상위 필드는 proxies, proxy-groups와 rules입니다. 일부 링크는 인코딩된 텍스트나 다른 클라이언트 전용 형식을 반환하므로 서버에서 Clash, Meta 또는 mihomo 호환 출력을 선택해야 합니다. 파일 확장자만으로 판단하지 마세요. 서버는 확장자가 없는 주소로 설정을 반환할 수 있습니다. 로컬에 다운로드한 뒤 텍스트 편집기로 확인하되, 편집기가 들여쓰기나 탭을 자동으로 바꾸지 않도록 주의하세요.

proxies:
  - name: "Example Node"
    type: socks5
    server: 192.0.2.10
    port: 1080

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - "Example Node"

rules:
  - MATCH,PROXY

위 예시는 YAML 계층을 설명하기 위한 것입니다. 목록 항목은 공백으로 들여쓰고 탭은 사용할 수 없습니다. 따옴표는 쌍을 이루어야 하며 같은 계층의 필드는 동일한 들여쓰기를 유지해야 합니다. 파싱 로그에 line과 column이 표시되면 오류가 난 줄보다 위쪽부터 확인하세요. 실제 들여쓰기 오류는 바로 앞 줄에 있을 수 있습니다. duplicate key는 같은 매핑에 중복 필드가 있다는 뜻이고, cannot unmarshal은 필드 유형이 예상과 다르다는 뜻인 경우가 많습니다. 예를 들어 배열이어야 할 값을 문자열로 작성한 경우입니다.

원격 업데이트와 로컬 덮어쓰기 구분

많은 GUI 클라이언트는 구독 위에 오버라이드, 스크립트 또는 추가 설정을 적용할 수 있습니다. 원격 원문은 유효하지만 오버라이드를 적용한 뒤 시작에 실패한다면 문제는 로컬 가공 계층에 있습니다. 오버라이드를 잠시 끄고 다시 로드하세요. 복구되면 사용자 지정 DNS, 규칙과 정책 그룹을 한 부분씩 다시 켭니다. 클라이언트 캐시에 있는 구독 파일을 직접 편집하지 마세요. 다음 업데이트에서 덮어쓰이고 문제 재현도 어려워집니다. 장기적으로 사용할 사용자 지정 내용은 클라이언트가 제공하는 명시적인 오버라이드 기능에 넣어야 합니다.

구독 업데이트는 성공했지만 노드가 없을 때는 먼저 응답에 proxies가 포함됐는지 확인한 다음 클라이언트가 새 설정을 선택했는지 점검하세요. 일부 클라이언트는 다운로드에는 성공해도 이전 설정을 계속 활성 상태로 유지하므로 수동 전환이 필요합니다. 또 다른 클라이언트는 일부 필드가 호환되지 않으면 설정 전체를 거부할 수 있습니다. 설정 목록의 업데이트 시간은 요청이 발생했다는 사실만 보여 줄 뿐 커널이 적용했다는 증거가 아닙니다. 커널 로그에 설정 로드 완료가 표시되고 정책 그룹에 노드가 나와야 업데이트 경로가 완료된 것입니다.

네트워크, 인증서와 업데이트 빈도 처리

구독 도메인에 접속하려면 프록시가 필요하지만 클라이언트는 노드를 얻기 위해 구독에 의존하는 순환 의존이 생길 수 있습니다. 최근 정상 작동한 로컬 설정을 보관하고, 이전 설정으로 먼저 네트워크를 만든 뒤 구독을 업데이트하세요. 유일하게 작동하는 설정을 삭제하지 마세요. 인증서 오류는 먼저 시간을 동기화하고 시스템 인증서 환경을 확인해야 합니다. 기업 네트워크에서 관리형 프록시를 사용한다면 해당 네트워크의 인증서와 접근 정책을 따라야 합니다.

업데이트 버튼을 반복해서 눌러도 서버의 요청 제한은 해결되지 않습니다. HTTP 429가 발생하면 기다린 뒤 다시 시도하세요. 401 또는 403은 대개 링크 만료, 계정 상태 또는 접근 파라미터를 가리키고, 404는 경로가 존재하지 않는다는 뜻이며, 5xx는 서버 장애일 가능성이 큽니다. 클라이언트에 짧은 오류만 표시된다면 개발자 로그나 명령줄 요청으로 상태 코드를 확인할 수 있지만 출력에 구독 주소가 포함되지 않도록 가려야 합니다.

안정적인 수정 후에는 구독 요청이 올바른 형식으로 반환되고, 문제가 있는 오버라이드가 비활성화되어 있으며, 로그에 설정 로드 성공이 표시되고, 정책 그룹에서 노드를 확인할 수 있으며, 재시작 후에도 같은 설정이 복구되는지 확인해야 합니다. 빠른 가져오기의 기본 단계는 빠른 시작에서 다시 확인할 수 있습니다. 서로 다른 커널의 필드 호환 범위를 이해하려면 Clash 원본, Meta와 mihomo 커널 차이를 읽어 보세요.

연결은 성공하지만 웹페이지·다운로드가 느리거나 영상이 끊김

속도 문제는 노드 목록의 지연 시간만으로 판단할 수 없습니다. 지연 시간은 작은 요청의 왕복 시간이고, 다운로드 속도는 원격 대역폭, 라우팅 혼잡, 패킷 손실, 프로토콜 오버헤드, 대상 사이트의 속도 제한과 로컬 장치 성능에도 영향을 받습니다. 지연이 낮은 노드라도 대역폭이 작을 수 있고, 지연이 조금 높은 노드가 대용량 파일에는 더 적합할 수 있습니다. 먼저 어떤 유형이 느린지 구분하세요. 도메인 최초 접속, 연결 수립, 지속적인 다운로드 또는 영상과 특정 웹사이트만 느린지 확인합니다.

직접 연결과 프록시 비교 기준 만들기

같은 장치와 네트워크에서 비슷한 시간대에 직접 연결과 프록시를 각각 테스트하세요. 장치를 바꿔 비교하지 말고 Wi-Fi와 유선 결과를 섞지도 마세요. 작은 웹페이지 하나와 지속적인 다운로드 작업 하나를 포함해 테스트하고, 순간적인 최고치가 아니라 안정화된 구간을 기록합니다. 직접 연결도 느리다면 무선 신호, 라우터 부하, 통신사 경로 또는 대상 서비스를 먼저 처리하세요. 프록시만 느리다면 노드와 프로토콜을 비교합니다.

백그라운드 동기화, 시스템 업데이트와 클라우드 업로드를 끄세요. 업로드 대역폭이 가득 차면 확인 패킷이 제때 돌아오지 못해 다운로드와 웹 접속이 함께 느려집니다. Wi-Fi에서는 액세스 포인트 가까이에서 테스트해 2.4GHz 간섭과 프록시 문제를 구분하세요. 유선은 정상인데 무선만 느리다면 Clash를 수정할 필요가 없습니다. 모바일 핫스팟에서는 신호 전환과 요금제의 속도 제한에 주의하세요. 짧은 측정 결과가 지속적인 전송 품질을 의미하지는 않습니다.

DNS 첫 응답과 연결 재사용 확인

웹페이지를 클릭한 뒤 한동안 빈 화면이 나타났다가 정상 속도로 로드된다면 DNS 또는 최초 연결 핸드셰이크가 느린 것이 흔한 원인입니다. 로그에서 도메인 조회 시간이明显하게 길면 먼저 DNS 장의 문제를 처리하세요. 같은 도메인에 매번 많은 연결을 새로 만든다면 브라우저 확장 프로그램, 보안 소프트웨어 또는 네트워크 중간 계층이 연결 재사용을 방해하는지 확인합니다. 클라이언트마다 동시 연결과 연결 풀은 커널이 관리하므로 출처를 알 수 없는 최적화 파라미터를 임의로 적용하지 마세요.

정책 그룹의 자동 테스트도 잘못된 판단을 만들 수 있습니다. URL Test는 지정된 테스트 주소만 기준으로 노드를 선택하며, 대상 동영상 사이트의 실제 경로는 완전히 다를 수 있습니다. 지속적인 전송에서는 두세 노드를 수동으로 비교하는 편이 더 정확합니다. Fallback은 현재 노드를 사용할 수 없을 때 전환하는 데 적합하고, Load Balance는 연결마다 출구를 바꿀 수 있습니다. 로그인 상태가 중요한 웹사이트는 출구가 바뀌면 다시 인증을 요구할 수 있습니다. 속도 문제를 점검하는 동안에는 고정 노드를 우선 사용해 정책 자동 전환 변수를 줄이세요.

MTU, IPv6와 TUN 성능 문제 식별

TUN 모드에서 작은 웹페이지는 열리지만 대용량 파일이 멈추거나 일부 이미지가 계속 완전히 로드되지 않는다면 MTU와 경로 분할이 원인일 수 있습니다. 먼저 무작정 MTU를 아주 작게 설정하지 마세요. 시스템 프록시와 TUN을 비교하고, 시스템 프록시는 정상인데 TUN만 이상할 때 가상 네트워크 인터페이스의 기본값, 하위 VPN 중첩과 라우터 경로를 점검합니다. 일부 네트워크는 IPv6 연결성이 완전하지 않아 IPv6을 먼저 시도한 뒤 실패를 기다리고 IPv4로 폴백하면서 지연이 생길 수 있습니다. 로그와 DNS 결과로 이 과정이 발생하는지 확인하세요.

# 요청 단계별 시간을 확인하고 name lookup, connect와 start transfer를 중점 비교
curl -o /dev/null -s \
  -w "dns=%{time_namelookup}\nconnect=%{time_connect}\ntls=%{time_appconnect}\nfirst_byte=%{time_starttransfer}\ntotal=%{time_total}\n" \
  --proxy http://127.0.0.1:7890 \
  https://example.com

클라이언트 자체의 리소스 사용량도 관찰해야 합니다. 대규모 규칙 세트, 많은 로그, 잦은 상태 확인과 복잡한 스크립트는 CPU와 메모리 부담을 높이며 저전력 장치에서 특히 두드러집니다. 먼저 디버그 로그를 끄고, 상태 확인 간격을 늘리며, 불필요한 오버라이드를 비활성화한 뒤 성능을 비교하세요. 라우터나 오래된 휴대폰에서 완전한 TUN을 실행하면 단일 코어 성능에 제한될 수도 있습니다. 이 경우 노드를 바꿔도 로컬 처리 병목은 해결되지 않습니다.

최종 기록에는 직접 연결 결과, 프록시 결과, 노드, 트래픽 가로채기 모드, DNS 단계별 소요 시간과 테스트 시간대를 포함해야 합니다. 문제가 TUN과 시스템 프록시의 차이에 집중된다면 TUN 모드와 시스템 프록시의 작동 방식 비교를 계속 읽어 보세요. 이 데이터가 있어야 노드를 바꿀지, 규칙을 수정할지, DNS를 조정할지 또는 로컬 무선 네트워크를 처리할지 판단할 수 있습니다.

DNS 조회 실패, 오염, 누출과 순환 조회

DNS 장애는 단순히 “서버를 찾을 수 없음”이라는 한 문장으로만 나타나지 않습니다. 도메인이 간헐적으로 열리지 않거나, 같은 웹사이트가 앱마다 다르게 보이거나, 프록시를 켜도 시스템 조회를 사용하거나, fake-ip 주소를 앱이 제대로 처리하지 못하거나, 내부 도메인이 작동하지 않거나, 조회 요청이 로컬 프록시와 시스템 리졸버 사이에서 순환하는 현상이 흔합니다. 먼저 조회 경로를 그려 보세요. 앱은 누구에게 조회를 맡기는지, Clash가 DNS를 리슨하는지, 상위 서버에 직접 연결하는지 프록시로 연결하는지, 최종 결과를 어느 구성 요소가 반환하는지 확인합니다.

조회 문제와 연결 문제 구분

nslookup, dig 또는 시스템 조회 명령으로 도메인 결과가 나오는지 확인한 뒤 로그에서 Clash가 조회를 받았는지 살펴보세요. 주소가 조회되는데도 연결이 시간 초과되면 문제는 노드나 대상 경로에 있을 수 있습니다. 순수 IP 요청은 되지만 도메인만 실패하면 DNS일 가능성이 높습니다. 브라우저가 별도의 보안 DNS를 사용할 수 있어 시스템 명령과 결과가 다를 수 있습니다. 점검하는 동안에는 브라우저 사용자 지정 DNS를 잠시 끄고 시스템 또는 Clash 경로 하나로 통일하세요.

# 시스템에서 현재 사용하는 조회 경로 확인
nslookup example.com

# macOS / Linux에서 A 및 AAAA 레코드 확인
dig example.com A
dig example.com AAAA

# 로컬 DNS 리스닝 포트를 지정할 때
dig @127.0.0.1 -p 1053 example.com

로컬 DNS 포트가 리스닝하지 않는다면 설정에서 DNS가 활성화됐는지, 포트가 사용 중인지, 커널에 바인딩 권한이 충분한지 확인하세요. 53번 포트는 보통 더 높은 권한이 필요하고 시스템 서비스와 충돌하기도 쉽습니다. 데스크톱 클라이언트는 내부 전달이나 높은 번호의 포트를 사용하는 경우가 많으므로 예시를 보고 53으로 강제 변경하지 마세요. 로그의 bind failed, address already in use와 permission denied는 각각 포트 사용 또는 권한 문제로 나누어 처리해야 합니다.

fake-ip와 redir-host의 경계 이해

fake-ip은 앱에 예약 주소를 반환하고 커널이 도메인 매핑을 관리하는 방식입니다. 도메인 기반 규칙 매칭이 쉬워지고 일부 우회 조회를 줄일 수 있습니다. 일부 LAN 장치 검색, 오래된 프로그램, 게임 플랫폼 또는 실제 주소를 직접 받아야 하는 서비스는 호환되지 않을 수 있으므로 fake-ip-filter에 추가해야 합니다. 모든 도메인을 필터 목록에 넣으면 fake-ip의 주요 기능을 잃게 됩니다. 로그에서 구체적인 도메인을 확인하고 필요한 내부 도메인 접미사, 장치 검색 도메인 또는 명확한 비호환 항목만 추가하세요.

dns:
  enable: true
  enhanced-mode: fake-ip
  listen: 127.0.0.1:1053
  nameserver:
    - https://1.1.1.1/dns-query
  fallback:
    - https://8.8.8.8/dns-query
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

예시의 상위 서버는 문법을 보여 주기 위한 것일 뿐이며, 실제 선택은 네트워크 연결성과 개인정보 보호 요구를 함께 고려해야 합니다. 암호화 DNS 주소 자체도 조회가 필요하며 이 과정은 bootstrap 또는 default-nameserver에 의존합니다. 모든 부트스트랩 조회를 프록시를 통해서만 접근할 수 있는 주소로 보내고, 프록시 노드 도메인도 해당 리졸버에 의존하게 만들면 시작 순환이 발생합니다. 합리적인 경로는 노드 도메인과 암호화 DNS 호스트 이름이 시작 단계에서 접근 가능한 리졸버를 통해 주소를 얻도록 한 뒤 Clash가 이후 요청을 가로채게 하는 것입니다.

DNS 누출과 다중 리졸버 공존 처리

DNS 누출의 핵심은 테스트 페이지에 몇 개의 서버가 표시되는지가 아니라 앱의 조회가 예상 경로를 우회하는지 여부입니다. 시스템 프록시는 일반적으로 프록시를 지원하는 앱의 연결만 가로채며 모든 시스템 DNS를 자동으로 가로채지는 않습니다. TUN과 DNS 가로채기를 함께 사용하면 범위가 넓어지지만 올바른 라우팅에 더 의존합니다. 브라우저 보안 DNS, 운영체제 암호화 DNS, 다른 VPN과 보안 소프트웨어를 먼저 확인해 여러 구성 요소가 조회를 동시에 차지하지 않도록 하세요. 전체 점검 방법은 Clash DNS 누출 탐지와 방지 설정을 참고하세요.

내부 도메인을 조회할 수 없다고 Clash DNS 설정 전체를 바로 삭제하지 마세요. 기업이나 가정 네트워크의 사설 도메인은 LAN DNS로만 조회되는 경우가 많으므로 nameserver-policy 또는 전용 도메인 규칙으로 내부 리졸버에 보낼 수 있습니다. 장치가 네트워크를 벗어나면 내부 리졸버에 접근할 수 없으므로 폴백을 허용해야 합니다. 검색 도메인에 의존하는 짧은 호스트 이름은 DHCP로 전달된 도메인 접미사가 필요할 수도 있습니다. 전체 도메인은 작동하지만 짧은 이름만 실패한다면 프록시 노드가 아니라 시스템 검색 도메인을 확인하세요.

복구 후 필요한 시스템과 브라우저 DNS 캐시를 정리하고 클라이언트를 한 번 재시작한 뒤 시스템 명령, 브라우저와 실제 앱을 각각 검증하세요. 로그에는 조회가 예상한 리스너로 들어오고 상위 요청에 접근할 수 있으며 반환된 주소와 연결 규칙이 일치하는지 나타나야 합니다. 재시작 후 문제가 재현되면 로그인 시 DNS를 다시 쓰는 다른 네트워크 도구가 있는지 확인하세요. DNS 점검의 끝은 테스트 페이지에 특정 이름이 표시되는 것이 아니라 조회 경로가 명확하고 앱 동작이 일관되며 내부·공용 도메인이 정책에 따라 작동하는 것입니다.

시스템 프록시는 켜졌지만 앱에 적용되지 않음

시스템 프록시는 모든 트래픽을 Clash로 강제하는 기능이 아닙니다. 지원하는 앱에 HTTP, HTTPS 또는 SOCKS 프록시 주소를 알려 주는 역할입니다. 브라우저는 보통 이를 읽지만 일부 게임, 명령줄 도구, 스토어 앱과 자체 네트워크 스택을 사용하는 소프트웨어는 무시할 수 있습니다. 클라이언트에 “시스템 프록시가 켜짐”이라고 표시되는 것은 설정 기록이 수행됐다는 뜻일 뿐, 대상 앱이 실제로 사용한다는 증거는 아닙니다. 운영체제 설정, 앱 설정과 로컬 프록시 로그를 함께 확인하세요.

시스템에 기록된 주소와 포트 확인

시스템 네트워크 설정을 열고 프록시 서버가 루프백 주소인지, 포트가 클라이언트의 현재 리스닝 값과 일치하는지 확인하세요. 설정 변경, 커널 전환 또는 여러 클라이언트 설치 후 이전 포트가 남아 있을 수 있습니다. Windows에서는 시스템 프록시, WinHTTP 프록시와 앱 자체 설정을 구분해야 합니다. macOS 프록시는 네트워크 서비스별로 저장되므로 Wi-Fi와 유선 설정이 다를 수 있습니다. Linux 데스크톱 환경의 전역 프록시도 모든 터미널 프로그램에 자동으로 적용되지는 않습니다.

# Windows: WinHTTP 프록시 상태 확인
netsh winhttp show proxy

# macOS: Wi-Fi 네트워크 서비스의 Web 프록시 확인
networksetup -getwebproxy Wi-Fi
networksetup -getsecurewebproxy Wi-Fi

# Linux / 일반 터미널: 환경 변수 확인
env | grep -i proxy

명령줄 프로그램은 보통 HTTP_PROXY, HTTPS_PROXY와 ALL_PROXY 환경 변수를 읽지만 실제 지원 여부는 프로그램마다 다릅니다. 환경 변수는 설정 후 시작되어 해당 값을 상속한 프로세스에만 적용됩니다. 이미 열려 있는 터미널과 편집기에는 이전 값이 남아 있을 수 있습니다. 설정한 뒤 터미널을 다시 열어 테스트하고, 테스트가 끝나면 값을 지워 클라이언트 종료 후에도 명령이 존재하지 않는 로컬 포트를 가리키지 않도록 하세요.

# 현재 터미널에서 임시로 HTTP 프록시 사용
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890

# SOCKS5를 사용하고 프록시에서 도메인 조회
export ALL_PROXY=socks5h://127.0.0.1:7890

# 테스트 후 정리
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY

우회 목록, PAC와 앱 독립 프록시 처리

시스템 우회 목록은 일치하는 주소를 직접 연결하게 합니다. 목록에 너무 넓은 와일드카드 규칙이 있으면 대상 사이트가 Clash에 전혀 들어오지 않을 수 있습니다. PAC 스크립트도 URL에 따라 DIRECT 또는 PROXY를 반환하므로 스크립트 캐시, 주소 만료 또는 규칙 오류로 일부 웹사이트에 프록시가 적용되지 않을 수 있습니다. 먼저 PAC를 끄고 고정 시스템 프록시로 확인하세요. 고정 프록시가 정상이라면 PAC 내용과 다운로드 상태를 별도로 점검합니다.

브라우저 확장 프로그램, 개발 도구, 컨테이너 환경과 IDE는 독립 프록시를 설정할 수 있습니다. 독립 설정의 우선순위가 시스템 프록시보다 높으면 클라이언트를 전환해도 영향을 받지 않습니다. 대상 앱의 네트워크 옵션을 확인해 “시스템 설정 사용”으로 되돌리거나 현재 로컬 포트를 직접 입력하세요. 시스템 프록시를 전혀 지원하지 않는 프로그램에는 TUN이 더 적합할 수 있지만, 앞선 장의 권한, 라우팅과 DNS가 정상적으로 작동하는지 먼저 확인해야 합니다.

규칙에 따른 직접 연결과 실제 미가로채기 구분

앱 요청이 Clash 연결 로그에 나타나지만 출구가 DIRECT로 표시된다면 시스템 프록시는 정상 작동하고 규칙이 직접 연결을 선택한 것입니다. 이때는 시스템 설정을 계속 수정하지 말고 일치한 규칙과 정책 그룹을 확인하세요. 로그에 요청이 전혀 없다면 앱이 프록시를 우회했거나 가로채지 못한 것입니다. 모드를 잠시 글로벌로 바꿔 규칙 분기를 확인할 수 있지만 테스트가 끝나면 원래대로 돌리고 해당 도메인이나 규칙 세트를 수정해야 합니다.

LAN 주소는 보통 직접 연결로 유지해야 합니다. 모든 트래픽이 로그에 나타나게 하려고 로컬 네트워크 대역 우회를 삭제하지 마세요. 프린터, NAS, 라우터 관리 페이지와 장치 검색에 문제가 생길 수 있습니다. 시스템 프록시의 “로컬 주소 우회”와 Clash 규칙의 사설 네트워크 DIRECT는 동시에 존재할 수 있으며 서로 다른 계층에서 작동합니다. 공용 대상 점검에는 명확한 공용 도메인을 사용해 LAN 예외의 영향을 피하세요.

검증할 때 브라우저 하나와 명령줄 도구 하나를 선택하세요. 브라우저는 시스템 프록시로 접속하고 명령줄은 프록시를 명시해 접속해야 하며, 두 요청 모두 로그에 나타나야 합니다. 이후 Clash를 끄고 시스템 프록시가 제거되어 직접 연결이 복구되는지 확인하세요. 시스템 프록시가 대상 프로그램을 지원하지 않는다면 “시스템 프록시 켜짐”을 강제 가로채기로 간주하지 말고 TUN을 검토하세요. 각 트래픽 가로채기 방식의 범위는 프록시 모드 비교 글에서 확인할 수 있습니다.

클라이언트 시작 실패, 갑작스러운 종료와 커널 반복 종료

클라이언트 충돌은 먼저 GUI 종료, 커널 프로세스 종료와 시스템의 강제 종료를 구분해야 합니다. UI는 닫혔지만 프록시가 계속 작동한다면 커널이 백그라운드에서 실행 중일 수 있습니다. UI는 정상인데 포트를 리슨하지 못하면 커널 시작 실패일 가능성이 있습니다. 프로그램 전체가 갑자기 사라진다면 시스템 충돌 보고서, 메모리 압박과 보안 정책도 확인해야 합니다. 로그를 저장하기 전에 반복해서 재시작하지 마세요. 연속 재시작은 최초 오류라는 가장 중요한 증거를 덮어쓸 수 있습니다.

빈 설정과 최근 변경부터 시작

충돌 직전의 마지막 작업을 떠올려 보세요. 구독 업데이트, TUN 활성화, 오버라이드 가져오기, 커널 전환, 클라이언트 업그레이드 또는 테마 변경이었는지 확인합니다. 클라이언트에 안전 모드가 있다면 마지막 설정 자동 로드를 먼저 끄세요. 없다면 설정 폴더를 백업한 뒤 최근 설정을 다른 곳으로 옮기고 빈 환경에서 시작합니다. 빈 설정으로 시작된다면 프로그램 본체는 대체로 정상이며 구독과 오버라이드를 하나씩 복구해야 합니다. 빈 설정에서도 충돌하면 런타임, 권한, 설치 파일과 시스템 로그를 확인하세요.

설정으로 인한 커널 종료는 보통 파싱 오류, 알 수 없는 필드, 존재하지 않는 노드를 참조하는 정책 그룹, 누락된 규칙 세트 파일 또는 포트 바인딩 실패를 남깁니다. 로그의 첫 fatal 또는 error를 기준으로 처리하고 이후에 나타나는 “커널이 종료됨”만 보지 마세요. 설정이 구독에서 왔다면 먼저 로컬 오버라이드를 끄세요. 특정 구독에서만 충돌한다면 민감 정보를 제거한 최소 설정을 보존해 원인을 찾습니다. 로그를 공유할 때는 노드 비밀번호와 구독 파라미터를 삭제하세요.

포트, 파일 권한과 디스크 상태 확인

포트 사용은 커널이 시작 직후 종료되는 원인이 될 수 있습니다. 다른 프록시 프로그램을 완전히 종료하고 작업 관리자나 활성 상태 보기에서 이전 커널이 남아 있는지 확인하세요. 설정 폴더에 쓰기 권한이 없으면 클라이언트가 캐시, 데이터베이스와 로그를 업데이트하지 못할 수 있으며 디스크 공간 부족도 쓰기 실패를 일으킵니다. 모든 권한 문제를 피하려고 장기간 관리자 권한으로 실행하지 마세요. 설정 폴더를 현재 사용자가 읽고 쓸 수 있는 위치에 두고 TUN에 필요한 권한 상승은 클라이언트의 공식 기능으로 처리하세요.

Windows에서는 이벤트 뷰어의 애플리케이션 오류에서 장애 모듈을 기록하세요. macOS에서는 시스템이 생성한 충돌 보고서를 확인합니다. Linux 데스크톱에서는 터미널에서 클라이언트를 시작하면 누락된 라이브러리, 권한과 그래픽 백엔드 오류를 확인할 수 있습니다. 서버 환경에서 mihomo를 실행한다면 systemd로 최근 로그를 확인해 종료 코드와 재시작 횟수를 점검하세요.

# Linux: 서비스 상태와 최근 로그 확인
systemctl status mihomo --no-pager
journalctl -u mihomo -n 120 --no-pager

# 설정 문법 확인, 경로는 실제 설치 위치에 맞게 조정
mihomo -t -f /etc/mihomo/config.yaml

업그레이드, 이전과 호환성 처리

클라이언트를 이전할 때 프로그램 데이터 폴더 전체를 복사하지 마세요. 클라이언트마다 데이터베이스, UI 설정, 오버라이드 형식과 커널 경로가 다릅니다. 더 안전한 방법은 구독 주소, 사용자 지정 규칙과 필요한 DNS 조각을 내보내고 새 클라이언트에서 설정을 다시 만드는 것입니다. 데스크톱에서는 Clash Plus를 우선 선택하고, 필요에 따라 Clash Verge Rev, FlClash, Clash Nyanpasu를 사용할 수 있습니다. Clash for Windows와 ClashX Meta는 유지 관리가 중단됐으므로 새로운 설정 호환 문제를 처리할 때 우선 선택하지 않는 것이 좋습니다.

업그레이드 후 시작에 실패하면 먼저 릴리스 노트에서 설정 디렉터리, 커널 인터페이스 또는 시스템 요구 사항이 변경됐는지 확인하세요. 이 사이트는 본문에 특정 버전 번호를 고정하지 않으며, 현재 사용 가능한 설치 파일은 다운로드 페이지에서 일괄 제공합니다. 재설치하기 전에 사용자 설정을 백업하고 시스템 절차에 따라 정상적으로 제거한 뒤 아키텍처에 맞는 소프트웨어를 설치하세요. ARM과 x64 설치 파일을 섞지 마세요. macOS에서는 Apple Silicon과 Intel도 구분해야 합니다. 설치 파일의 아키텍처가 잘못되면 바로 시작되지 않거나 변환 계층을 통해 실행되더라도 성능과 확장 권한 문제가 생길 수 있습니다.

시스템 보안 소프트웨어가 차단한다면 명확한 차단 이벤트와 파일 경로를 확인하고 추측만으로 전체 보호 기능을 끄지 마세요. 기업 관리 장치는 VPN 생성, 네트워크 확장 프로그램 설치 또는 승인되지 않은 프로그램 실행을 금지할 수 있으며, 이런 제한은 장치 관리자에게 처리해야 합니다. 파일이 격리됐다면 먼저 다운로드 출처가 이 사이트가 제공한 해당 클라이언트 입구인지 확인한 뒤 시스템 정책에 따라 복원하거나 다시 설치하세요. 출처를 알 수 없는 재배포 페이지에서 누락된 구성 요소를 가져오지 마세요.

충돌 복구의 검증은 “UI가 열리는가”만으로 끝나지 않습니다. 커널이 계속 실행되는지, 로컬 포트가 안정적으로 리스닝하는지, 설정이 문법 검사를 통과하는지, 시스템 프록시를 정상적으로 켜고 끌 수 있는지 확인하고 시스템을 재시작한 뒤 다시 검증해야 합니다. 빈 설정은 안정적이지만 특정 사용자 지정 설정을 복구한 뒤 다시 종료된다면 해당 부분을 계속 줄여 최소 재현 조건을 찾아야 합니다. 여러 클라이언트를 반복 설치하는 것보다 이 과정이 확실한 결론을 얻기 쉽습니다.

Android와 iOS 모바일 전용 점검

모바일 클라이언트는 시스템 VPN 인터페이스를 통해 트래픽을 가로채므로 문제는 설정 문법보다 시스템의 생명주기 관리에서 발생하는 경우가 많습니다. 화면을 끄면 연결이 끊기거나, Wi-Fi에서 셀룰러 네트워크로 전환한 뒤 멈추거나, 특정 앱만 연결되지 않거나, VPN 표시가 반복해서 사라진다면 백그라운드 권한, 항상 켜진 VPN, 저전력 모드, 데이터 절약 기능과 다른 VPN 충돌을 확인해야 합니다. 모바일 장치는 보통 한 번에 하나의 VPN 터널만 유지할 수 있으므로 광고 차단기, 기업 VPN과 Clash 클라이언트가 같은 인터페이스를 동시에 사용할 수 없습니다.

Android: 백그라운드, VPN 권한과 앱별 우회

Android에서 처음 연결할 때 VPN 승인 대화상자가 표시됩니다. 승인하지 않으면 클라이언트가 설정을 가져올 수는 있어도 시스템 터널을 만들 수 없습니다. 연결 버튼을 눌렀는데 즉시 연결 해제 상태로 돌아가면 먼저 권한이 취소됐는지 확인하세요. 일부 제조사 시스템은 화면이 꺼진 뒤 백그라운드 프로세스를 제한하므로 클라이언트를 백그라운드 실행 허용 또는 배터리 최적화 제외 목록에 추가하고 자동 시작도 허용해야 합니다. 설정 이름은 장치마다 다르지만 목적은 같습니다. 터널이 작동하는 동안 시스템이 클라이언트 프로세스를 중지하지 않아야 합니다.

특정 앱만 프록시를 사용하지 않는다면 앱별 트래픽 분기 또는 VPN 우회 목록을 확인하세요. 앱별 프록시는 지정한 프로그램만 프록시하거나 특정 프로그램을 제외할 수 있으며, 모드를 반대로 선택하면 대부분의 앱이 직접 연결됩니다. “VPN을 사용하지 않는 연결 차단”을 켜기 전에 부팅과 네트워크 전환 후 클라이언트가 안정적으로 재연결되는지 먼저 확인하세요. 그렇지 않으면 클라이언트가 잠시 종료될 때 장치 전체가 인터넷에 연결되지 않는 것처럼 보입니다. 점검 단계에서는 이 제한을 끄고 안정화한 뒤 필요에 따라 다시 켜세요.

Wi-Fi에서 셀룰러 네트워크로 전환한 뒤 복구되지 않으면 먼저 터널 연결을 끊었다가 다시 연결하고, 로그에서 노드 도메인을 다시 조회하고 연결을 수립하는지 관찰하세요. 모바일 네트워크가 IPv6을 우선 제공하지만 현재 노드 도메인이나 DNS 경로는 IPv4만 지원할 수 있습니다. Private DNS와 클라이언트 DNS가 동시에 작동할 수도 있습니다. Android Private DNS를 잠시 자동으로 설정하고 클라이언트 기본 DNS 경로로 다시 테스트하세요. 복구되면 어느 한쪽의 조회 메커니즘만 유지할지 결정합니다.

iOS: VPN 설정, 주문형 연결과 네트워크 전환

iOS에서 처음 활성화할 때 VPN 구성 추가를 허용해야 합니다. 시스템 설정에 유사한 구성이 여러 개 있다면 현재 활성화된 항목이 Clash Plus에 해당하는지 확인하세요. 이 사이트는 모바일에서 Clash Plus를 우선 권장하며, 앱은 App Store에서 설치합니다. 공식 사이트 정보는 iOS 다운로드 입구에서 확인할 수 있습니다. 연결 후 VPN 상태가 표시되지 않으면 시스템 VPN 페이지에서 연결을 시도 중인지 즉시 해제되는지 확인한 뒤 클라이언트로 돌아와 로그를 읽으세요.

저전력 모드와 시스템 리소스 회수는 백그라운드 유지에 영향을 줄 수 있지만 정상적인 Network Extension은 시스템이 관리해야 합니다. 클라이언트를 수동으로 강제 종료하면 터널이 멈출 수 있으므로 점검 중에는 멀티태스킹 화면에서 앱을 자주 쓸어 닫지 마세요. 주문형 연결 규칙이 잘못 설정되면 Wi-Fi에서는 연결되고 셀룰러에서는 끊기거나 특정 네트워크에서 반복적으로 재연결할 수 있습니다. 먼저 복잡한 주문형 규칙을 끄고 수동으로 안정적인 연결을 만든 뒤 네트워크 조건을 하나씩 복구하세요.

모바일 구독과 인증서 문제

모바일 브라우저에서 구독 링크를 복사할 때 실제 링크가 아니라 페이지에 표시된 텍스트를 복사하기 쉽습니다. 서비스 페이지의 복사 버튼을 사용하고 붙여 넣은 뒤 시작과 끝을 확인하세요. 스크린샷을 보고 직접 입력하지 마세요. Wi-Fi에서는 구독 업데이트가 실패하지만 셀룰러에서는 성공한다면 현재 Wi-Fi의 인증 페이지와 DNS를 확인하고, 반대라면 셀룰러 데이터 권한을 확인합니다. 시스템 설정에서 클라이언트의 모바일 데이터 사용을 금지하면 터널 UI는 존재해도 구독 업데이트와 노드 연결이 모두 실패할 수 있습니다.

시스템 시간은 모바일 TLS에도 영향을 줍니다. 자동 날짜와 시간대를 켜세요. 공용 Wi-Fi는 웹 인증을 먼저 요구하는 경우가 많아 VPN이 먼저 트래픽을 가로채면 인증 페이지가 나타나지 않을 수 있습니다. 이때 Clash를 먼저 끄고 네트워크에 로그인한 뒤 직접 연결로 웹페이지가 열리는지 확인하고 터널을 만드세요. 공용 네트워크를 벗어난 뒤 인증 상태가 남아 있다면 프록시 설정을 수정하는 것보다 Wi-Fi를 껐다 켜는 편이 효과적입니다.

모바일에서는 최종적으로 네 차례 검증해야 합니다. Wi-Fi에서 연결하고 접속하기, 셀룰러로 전환한 뒤 계속 접속하기, 몇 분간 화면을 잠근 뒤 다시 접속하기, 클라이언트를 재시작한 뒤 구독을 다시 로드하기입니다. 매번 VPN 표시와 로그를 확인하세요. 같은 네트워크와 구독에서 Android와 iOS가 모두 실패하면 노드나 구독 문제일 가능성이 높고, 한 장치에서만 실패하면 해당 장치의 권한, DNS와 시스템 제한을 확인해야 합니다. 재설치가 필요하다면 Android는 Android 다운로드 영역에서 Clash Plus, Clash Meta for Android, FlClash 또는 Surfboard를 선택할 수 있습니다. iOS는 Clash Plus 스토어 입구를 사용하세요.

점검이 끝나면 장치 운영체제, 클라이언트, 트래픽 가로채기 모드, 문제가 발생한 네트워크, 로그 키워드, 변경한 항목과 최종 결과를 짧게 기록해 두세요. 다음에 같은 증상이 발생하면 모든 설정을 다시 시도하지 말고 이미 검증한 단계를 재사용하세요. 클라이언트 프로젝트 관계와 커널 출처가 궁금하다면 Clash 오픈 소스 생태계 프로젝트 관계도를 읽어 그래픽 클라이언트, 커널과 모바일 구현을 혼동하지 않도록 하세요.