Clash 초보부터 고급까지: 클라이언트·구독·규칙 분할

1. 핵심 개념: 클라이언트, 커널과 트래픽 경로

Clash를 이해하는 첫 단계는 설정 항목을 외우는 것이 아니라 세 가지 계층을 구분하는 것입니다. 클라이언트 인터페이스, 프록시 커널, 외부 구독 서비스가 그것입니다. 클라이언트는 설정 파일, 정책 그룹, 연결 상태와 시스템 스위치를 표시합니다. mihomo는 YAML을 실제로 해석하고 규칙을 매칭하며 프록시 연결을 수립하는 커널입니다. 구독 서비스는 하나 이상의 노드와 정책 설정을 제공합니다. 소프트웨어마다 메뉴 이름이 비슷할 수 있지만 커널, 설정 형식, 시스템 트래픽 제어 방식이 다르면 결과도 달라질 수 있습니다.

일반적인 웹 요청은 보통 애플리케이션이 시스템 네트워크 스택에 전달한 뒤, 클라이언트에서 활성화한 시스템 프록시, 강화 모드 또는 TUN 제어를 거쳐 커널로 들어갑니다. 커널은 현재 설정을 읽고 DNS, 규칙 매칭, 정책 그룹 선택, 아웃바운드 연결을 차례로 처리한 다음 응답을 애플리케이션에 돌려줍니다. 규칙 모드에서는 도메인이 먼저 DNS로 해석될 수도 있고, 도메인 형태 그대로 매칭에 사용될 수도 있습니다. 구체적인 동작은 DNS 모드, 스니핑 설정과 설정 파일 작성 방식에 따라 달라집니다. 따라서 ‘클라이언트가 실행 중’이라는 사실만으로 모든 애플리케이션이 프록시를 거친다고 볼 수는 없습니다.

1.1 설정 파일, 프록시 그룹과 노드의 차이

노드는 서버 주소, 포트와 프로토콜 관련 매개변수를 포함한 구체적인 아웃바운드 연결 정의입니다. 프록시 그룹은 여러 노드 또는 다른 정책 그룹 중에서 선택하는 기능으로, 수동 선택, 자동 선택, 장애 조치, 부하 분산 등이 흔히 사용됩니다. 설정 파일은 프록시, 프록시 그룹, 규칙, DNS와 포트 등을 하나로 묶습니다. 하나의 노드는 여러 프록시 그룹에서 참조할 수 있고, 프록시 그룹은 다른 프록시 그룹을 구성원으로 포함할 수도 있습니다. 정책 그룹 이름은 보이지만 선택 가능한 항목이 없다면 노드 해석에 실패했거나 그룹에서 참조한 이름이 실제 프록시 이름과 일치하지 않는 경우가 많습니다.

‘프록시 포트’와 ‘혼합 포트’도 같은 것으로 보면 안 됩니다. HTTP 포트는 HTTP 프록시 요청만 받고, SOCKS 포트는 SOCKS 요청을 받으며, 혼합 포트는 일반적으로 두 주요 프로토콜을 모두 지원합니다. 시스템 프록시에는 보통 혼합 포트나 클라이언트가 명시한 HTTP 포트만 입력하면 됩니다. 제어 포트를 시스템 프록시에 잘못 입력하면 브라우저에는 연결 실패가 표시되지만 클라이언트 자체는 계속 실행될 수 있습니다. 제어 포트는 외부 API나 인터페이스 통신에만 사용되며 일반 웹 트래픽을 처리하지 않습니다.

1.2 관찰 가능한 판단 순서 세우기

문제를 점검할 때는 ‘애플리케이션이 요청을 보냈는가, 시스템이 요청을 클라이언트로 전달했는가, 클라이언트가 규칙을 매칭했는가, 정책 그룹이 유효한 아웃바운드를 선택했는가, 원격 연결이 성공했는가’의 순서로 확인하는 것이 좋습니다. 처음부터 DNS나 규칙을 대량으로 수정하지 마세요. 먼저 클라이언트의 연결 목록, 로그 또는 요청 목록에서 대상 도메인을 확인합니다. 기록이 전혀 없다면 시스템 프록시, TUN 또는 애플리케이션 자체의 프록시 지원 문제일 가능성이 큽니다. 요청은 있지만 규칙 결과가 DIRECT라면 현재 규칙에 따른 정상 동작일 수 있으므로 규칙 순서를 확인해야 합니다. 프록시 그룹에 매칭됐지만 모든 연결이 실패한다면 노드, 네트워크와 TLS를 점검합니다.

2. 클라이언트 선택: 플랫폼, 커널과 제어 범위에 맞춰 설치하기

클라이언트는 인터페이스 취향보다 먼저 플랫폼과 사용 범위를 기준으로 선택해야 합니다. Windows, macOS, Linux에서는 시스템 프록시, 설정 관리와 로그 확인을 제공하는 데스크톱 클라이언트가 일반적으로 필요합니다. Android는 모바일 시스템 VPN 인터페이스에 맞는 클라이언트가 필요하고, iOS에서는 App Store에서 Clash Plus를 설치합니다. 서버, 투명 게이트웨이 또는 장시간 백그라운드 실행 환경이라면 mihomo 커널을 직접 사용하는 편이 적합하지만, 데스크톱 클라이언트의 그래픽 설정 메뉴가 없으므로 유지 관리 난도가 높습니다.

이 사이트의 다운로드 페이지에서는 각 플랫폼의 첫 번째 항목으로 Clash Plus를 안내합니다. 지원 범위가 비교적 넓고 통일된 조작 방식을 원하는 사용자에게 적합하기 때문입니다. Clash Verge Rev, FlClash, Clash Nyanpasu, ClashX Meta 등 다른 클라이언트도 플랫폼별 특징이 있습니다. 유지 관리가 중단된 소프트웨어가 오래된 기기에서 실행될 수는 있지만 새로 설치할 때 우선 선택해서는 안 됩니다. 설치 전에는 시스템 아키텍처와 패키지 형식을 확인하세요. Windows는 설치 프로그램이나 압축 파일이 흔하고, macOS는 Intel과 Apple Silicon을 구분해야 하며, Linux는 배포판이 지원하는 설치 형식을 확인해야 합니다.

2.1 설치 전 확인할 세 가지

첫째는 플랫폼 아키텍처입니다. Windows ARM64 기기에서는 AMD64 전용 프로그램을 바로 사용할 수 없고, macOS의 Apple Silicon과 Intel 버전도 혼용해서는 안 됩니다. 둘째는 클라이언트 실행 권한입니다. 시스템 프록시, 시작 시 실행과 TUN에는 보통 추가 시스템 권한이 필요합니다. 설치 프로그램이 열렸다고 해서 해당 권한까지 부여된 것은 아닙니다. 셋째는 설정 출처입니다. 신뢰할 수 있는 구독 메뉴에서만 주소를 복사하고, 웹페이지 주소나 제어판 주소 또는 설명 문구가 섞인 전체 내용을 구독 입력란에 붙여넣지 마세요.

다운로드가 끝나면 먼저 클라이언트를 실행하고 시스템 프록시, TUN과 브라우저 확장을 한꺼번에 활성화하지 마세요. 인터페이스가 정상적으로 로드되고 설정 파일 또는 빈 설정 목록이 표시되는지 확인한 뒤 다음 설정으로 넘어가세요. 이렇게 하면 한 번에 하나의 변수만 바뀌므로 오류가 설치, 가져오기 또는 시스템 트래픽 제어 중 어디에서 발생했는지 명확히 알 수 있습니다. 설치 경로, 로그 경로와 설정 저장 위치는 클라이언트마다 다릅니다. 기기를 옮길 때는 클라이언트의 내보내기 기능을 우선 사용하고, 형식을 알 수 없는 캐시 디렉터리를 그대로 복사하지 마세요.

2.2 그래픽 클라이언트와 커널 직접 실행의 선택

그래픽 클라이언트는 개인용 컴퓨터에 적합합니다. 설정 업데이트, 정책 그룹 전환, 연결 로그와 시스템 프록시 스위치를 제공하기 때문입니다. 커널 직접 실행은 라우터, 서버 또는 컨테이너 환경에 적합합니다. 파일과 명령으로 설정을 관리해 데스크톱 계층 의존성을 줄일 수 있지만 프로세스 감시, 파일 권한, 로그 순환과 라우팅 포워딩을 직접 처리해야 합니다. 두 방식은 설정 개념을 공유하지만 모든 데스크톱 버튼에 대응하는 명령줄 매개변수가 있다고 가정해서는 안 됩니다.

3. 구독 가져오기: 설정 생성, 업데이트와 롤백

구독 주소는 본질적으로 설정 내용을 반환하는 URL입니다. 클라이언트가 주소를 요청하면 전체 YAML, 인코딩된 노드 모음 또는 서버가 클라이언트 유형에 맞춰 생성한 설정을 받을 수 있습니다. 가져올 때는 주소를 일반 노드처럼 하나씩 추가하지 말고 클라이언트의 ‘구독 관리’, ‘설정 파일’ 또는 유사한 메뉴를 사용하세요. 처음 가져온 뒤에는 설정 이름, 프록시 수, 정책 그룹과 규칙이 표시되는지 확인한 다음 활성화 여부를 결정합니다.

구독을 가져오기 전에 현재 정상 작동하는 설정을 하나 보관하는 것이 좋습니다. 많은 클라이언트가 업데이트 과정에서 기존 파일을 덮어쓰기 때문에 새 내용이 비어 있거나 형식이 잘못되었거나 정책 그룹 이름이 바뀌면 롤백 파일로 작업 상태를 복구할 수 있습니다. 구독을 업데이트할 때는 업데이트 버튼의 성공 표시만 보지 말고 설정 상세에서 업데이트 시간, 해석 상태와 프록시 그룹 구성원을 확인하세요. 서버가 HTTP 성공을 반환했지만 본문이 로그인 페이지나 오류 메시지인 경우도 있습니다. 이때 클라이언트는 해석 실패만 보고할 수 있으므로 실제 원인은 구독 주소의 응답 내용을 확인해야 합니다.

3.1 가져온 뒤 최소 확인 항목

첫째, 프록시 그룹에 구성원이 있는지 확인합니다. 흔히 사용하는 기본 그룹 이름은 ‘노드 선택’, ‘Proxy’ 또는 서비스 제공업체가 지정한 이름일 수 있습니다. 이름이 다르다고 기능까지 다른 것은 아닙니다. 둘째, 현재 선택된 항목이 실제 노드 또는 사용 가능한 하위 정책 그룹인지 확인하세요. 이미 삭제된 이름이 선택된 상태로 남아 있어서는 안 됩니다. 셋째, 규칙이 존재하는지 확인합니다. 규칙이 없는 설정도 전역 모드에서는 작동할 수 있지만 규칙 모드에서는 대부분의 요청이 기본 정책으로 떨어질 가능성이 큽니다. 넷째, DNS 설정이 현재 네트워크 환경과 호환되는지 확인합니다. 특히 fake-ip를 켜면 LAN 기기와 일부 로컬 서비스에 추가 규칙이 필요할 수 있습니다.

구독 업데이트는 자주 할수록 좋은 것이 아닙니다. 업데이트하면 설정을 다시 다운로드하고 프록시 그룹을 재구성하며 노드 상태 확인이 실행될 수 있습니다. 평소에는 서비스 제공업체의 권장 주기에 맞춰 업데이트하세요. 설정이 안정적이라면 클라이언트에 알림이 표시된다는 이유만으로 반복해서 누를 필요가 없습니다. 업데이트에 실패하면 기존 설정을 유지하고 실패 시간과 오류 문구를 기록한 뒤 네트워크 연결, 구독 권한, 주소 인코딩과 서버 응답 유형을 확인하세요.

3.2 설정 파일을 계층적으로 이해하기

설정은 기본 파일, 구독 내용과 로컬 오버라이드의 세 계층으로 이해할 수 있습니다. 기본 파일은 포트, 로그와 DNS 같은 공통 설정을 정의하고, 구독 내용은 노드와 정책 그룹을 제공하며, 로컬 오버라이드는 규칙을 조정하거나 LAN 직접 연결을 추가하고 모드를 변경합니다. 클라이언트마다 오버라이드 기능의 이름과 병합 규칙이 완전히 같지는 않으므로 수정 전에 특정 편집 상자의 일부만 보지 말고 최종 생성 설정을 확인해야 합니다. 설정 검증 기능을 지원한다면 저장 후 먼저 검증한 다음 활성화하세요.

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

proxies: []
proxy-groups:
  - name: 노드 선택
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,lan,DIRECT
  - GEOIP,LAN,DIRECT
  - MATCH,노드 선택

위의 조각은 설정의 뼈대를 보여 줍니다. 혼합 포트는 로컬 HTTP 및 SOCKS 요청에 사용되고, 규칙 모드는 요청을 순서대로 처리하며, LAN 접근은 기본적으로 외부에 공개하지 않고, 마지막 MATCH가 기본 처리 역할을 합니다. 이는 특정 구독 서비스의 전체 설정이 아니므로 서비스 제공업체가 제공한 노드 내용을 대신할 수 없습니다. YAML을 편집할 때는 들여쓰기, 콜론 뒤의 공백과 목록 계층에 특히 주의하세요. 불필요한 Tab 하나나 잘못된 들여쓰기만으로도 파일 전체를 해석할 수 없게 됩니다.

4. 프록시 모드: 규칙·전역·직접 연결 확인 방법

프록시 모드는 요청이 정책 선택으로 들어가는 방식을 결정합니다. 규칙 모드는 설정 파일의 rules를 위에서 아래로 매칭하고, 일치하면 오른쪽에 지정된 정책 그룹으로 전달합니다. 전역 모드는 일반적으로 모든 요청을 하나의 프록시 그룹으로 보내므로 도메인 규칙에 따라 DIRECT 또는 프록시를 결정하지 않습니다. 직접 연결 모드는 요청이 프록시를 우회하도록 합니다. 클라이언트마다 버튼 이름은 조금 다를 수 있지만 현재 모드, 현재 정책 그룹과 개별 요청의 실제 결과를 함께 확인해야 한다는 원칙은 같습니다.

규칙 모드는 LAN, 중국 본토에서 자주 사용하는 서비스와 프록시가 필요한 대상을 나눠 처리할 수 있어 일상적인 사용에 적합합니다. 전역 모드는 짧은 테스트에 유용합니다. 규칙 결과가 확실하지 않을 때 알려진 프록시 그룹 하나로 대상을 통일하면 문제가 규칙에 있는지 연결 자체에 있는지 판단할 수 있습니다. 직접 연결 모드는 원래 네트워크 상태를 확인하거나 프록시 때문에 발생한 인증서, DNS 또는 로그인 문제를 점검할 때 적합합니다. 테스트가 끝나면 적절한 모드로 되돌리세요. 그렇지 않으면 브라우저 동작이 평소와 달라질 수 있습니다.

4.1 로그로 모드 적용 여부 확인하기

모드를 선택한 뒤 연결 로그를 열고 확실한 테스트 웹사이트에 접속하거나 기존 페이지를 새로 고침하세요. 기록에는 보통 요청 도메인, 매칭된 규칙, 선택된 정책 그룹과 최종 아웃바운드가 표시됩니다. 요청이 DIRECT에 매칭되면 현재 규칙 모드인지, 규칙에서 직접 연결을 명시했는지 먼저 확인하세요. 프록시 그룹에 매칭됐지만 페이지가 열리지 않는다면 그룹 내 다른 사용 가능한 노드로 전환해 오류가 달라지는지 관찰합니다. 로그에 요청이 나타나지 않는다면 트래픽이 아직 클라이언트에 들어오지 않은 것이므로 시스템 프록시, 브라우저의 독립 프록시 설정, TUN 상태 또는 애플리케이션의 자체 네트워크 경로를 확인해야 합니다.

‘웹페이지가 열린다’를 유일한 확인 기준으로 삼지 마세요. 브라우저가 캐시, IPv6, 애플리케이션 자체 프록시 설정 또는 기존 연결을 사용할 수 있습니다. 캐시를 비운 뒤 다시 로드하거나 클라이언트 연결 기록에서 새 요청이 실제로 생성되었는지 확인하세요. 명령줄로 확인할 때는 시스템 환경 변수에 의존하는 것보다 프록시 포트를 명시하는 편이 정확합니다.

curl --proxy http://127.0.0.1:7890 https://example.com/
curl --socks5-hostname 127.0.0.1:7890 https://example.com/

첫 번째 명령은 HTTP 프록시를 사용하고, 두 번째 명령은 SOCKS5를 사용하며 도메인 해석을 프록시에서 수행합니다. HTTP 명령은 실패하지만 SOCKS5가 성공한다면 포트 프로토콜이나 클라이언트 리스닝 설정이 맞지 않을 수 있습니다. 둘 다 실패하면 노드 연결과 로그를 확인하세요. 예시의 도메인은 명령 형식을 확인하기 위한 것이므로 실제 테스트에서는 정상적으로 접속할 수 있고 명령줄 요청을 허용하는 대상을 선택해야 합니다.

4.2 시스템 프록시, 앱 프록시와 TUN의 차이

시스템 프록시는 시스템 프록시 설정을 따르는 브라우저와 데스크톱 앱에 주로 적용되며 변경 범위가 작고 끄기 쉽다는 장점이 있습니다. 시스템 프록시를 따르지 않는 프로그램은 계속 직접 연결할 수 있습니다. 앱 프록시는 프로그램 내부 설정으로, 브라우저 확장, 개발 도구와 터미널이 서로 다른 메뉴를 사용할 수 있습니다. TUN은 더 낮은 네트워크 계층에서 트래픽을 제어하므로 적용 범위가 넓지만 가상 네트워크 카드, 시스템 권한, 라우팅과 DNS가 관련됩니다. 설정이 잘못되면 영향 범위도 커집니다. 문제를 점검할 때는 시스템 프록시부터 시작하고 대상 앱이 적용되는지 확인한 뒤 TUN을 고려하세요.

5. 규칙 분할: 매칭 순서, 정책 그룹과 사용자 지정 규칙

규칙 분할의 핵심은 순서입니다. 커널은 첫 번째 규칙부터 판단하며 요청이 매칭되는 즉시 다음 규칙을 확인하지 않고 규칙 오른쪽에 지정된 정책 그룹 또는 DIRECT, REJECT 등의 동작으로 전달합니다. 따라서 범위가 지나치게 넓은 규칙을 앞에 두면 뒤의 더 구체적인 규칙이 무시될 수 있습니다. 사용자 지정 규칙을 만들 때는 먼저 대상과 범위를 정하고, 규칙 유형을 선택한 다음 올바른 위치에 배치하세요. 특정 도메인이 열리지 않는다는 이유만으로 MATCH를 무작정 추가해서는 안 됩니다.

자주 사용하는 규칙 유형으로는 하나의 도메인과 정확히 일치하는 DOMAIN, 도메인과 하위 도메인에 일치하는 DOMAIN-SUFFIX, 키워드로 매칭하는 DOMAIN-KEYWORD, IPv4 대역에 매칭하는 IP-CIDR, IPv6 대역에 매칭하는 IP-CIDR6, IP 지리 데이터베이스로 매칭하는 GEOIP, 프로세스 이름으로 매칭하는 PROCESS-NAME이 있습니다. 프로세스 이름, 네트워크 스택과 스니핑 지원 여부는 커널 버전과 플랫폼에 따라 다를 수 있으므로 현재 클라이언트의 커널 기능을 먼저 확인하세요. 규칙 범위가 넓을수록 오매칭 가능성이 높으므로 정확한 도메인이나 명확한 접미사를 우선 사용합니다.

5.1 규칙 그룹 구성 방식

정책 그룹은 ‘수동 선택’과 ‘용도별 분할’의 두 계층으로 나누는 것이 좋습니다. 수동 선택 그룹에는 실제 노드나 자동 선택 그룹을 넣어 현재 아웃바운드를 결정하게 하고, 용도별 분할 그룹은 유형별 요청을 수동 선택, DIRECT 또는 다른 그룹으로 전달합니다. 광고 차단, LAN, 스트리밍과 기본 요청을 각각의 그룹으로 나눌 수 있습니다. 이렇게 하면 노드를 변경할 때 수동 선택 그룹만 수정하면 되므로 규칙 구조는 안정적으로 유지됩니다. 많은 노드를 각 업무 그룹에 직접 작성하면 구독 업데이트 후 이름이 바뀔 때 여러 곳을 수정해야 합니다.

정책 그룹 이름은 설정에서 참조되는 키이므로 대소문자, 공백과 문장 부호까지 완전히 일치해야 합니다. 아래 예시는 작은 구조를 보여 줍니다.

proxy-groups:
  - name: 노드 선택
    type: select
    proxies:
      - 자동 선택
      - DIRECT

  - name: 자동 선택
    type: url-test
    url: http://www.gstatic.com/generate_204
    interval: 300
    proxies:
      - 노드 1
      - 노드 2

rules:
  - DOMAIN-SUFFIX,lan,DIRECT
  - DOMAIN-SUFFIX,example.org,노드 선택
  - GEOIP,LAN,DIRECT
  - MATCH,노드 선택

url-test 그룹은 설정에 따라 사용 가능 여부를 테스트하고 결과가 좋은 구성원을 선택하지만, 테스트 주소에 접속할 수 있다고 해서 모든 대상에도 접속할 수 있는 것은 아닙니다. interval도 지나치게 짧게 설정하지 마세요. select 그룹은 사용자가 직접 선택합니다. 예시의 노드 이름은 proxies 영역에 실제로 존재해야 하며, 해당 노드가 없는 설정에 그대로 복사해서는 안 됩니다.

5.2 사용자 지정 규칙 검증 절차

규칙을 하나 추가한 뒤 바로 두 번째 규칙을 추가하지 마세요. 먼저 설정을 저장하고 다시 로드한 다음 대상 범위에 분명히 속하는 도메인에 접속하고, 로그에서 규칙 문구와 정책 그룹을 확인합니다. 매칭되지 않는다면 실제 도메인이 다른 접미사를 사용하거나, 요청이 IP로 전달되거나, DNS 결과가 스니핑되지 않았거나, 앞선 규칙이 먼저 처리했을 수 있습니다. 매칭됐지만 연결되지 않는다면 규칙 매칭은 성공한 것이므로 정책 그룹과 아웃바운드 연결을 확인해야 합니다.

규칙이 많을 때는 주석으로 용도별 구간을 나눌 수 있지만 해석할 수 없는 설명 문구를 핵심 필드에 넣어서는 안 됩니다. 구독에서 자동 생성된 규칙 세트를 사용하는 경우 먼저 규칙 세트의 업데이트 상태와 참조 이름을 확인한 뒤 로컬 규칙을 추가하세요. 로컬 규칙과 구독 규칙이 충돌한다면 어느 쪽을 우선할지 명확히 하고, 업데이트 후 최종 설정을 다시 확인합니다. 이 사이트의 자주 묻는 질문에는 정책 그룹이 비어 있는 문제, 규칙이 적용되지 않는 문제와 구독 업데이트 오류 등 자주 발생하는 점검 항목이 정리되어 있습니다.

6. TUN 모드: 가상 네트워크 카드, DNS와 시스템 트래픽 제어

TUN 모드는 가상 네트워크 인터페이스로 시스템 계층의 트래픽을 받은 뒤 커널이 설정에 따라 전달하는 방식입니다. 시스템 프록시를 따르지 않는 프로그램까지 포함할 수 있어 단말 트래픽을 통합적으로 제어해야 할 때 적합합니다. 동시에 일반 시스템 프록시보다 시스템 네트워크 하위 계층에 가깝기 때문에 라우팅과 DNS 동작이 바뀝니다. TUN은 ‘더 빠른 프록시 모드’가 아니라 트래픽이 들어오는 다른 경로입니다. 활성화하기 전에 일반 시스템 프록시가 정상적으로 작동하는지 확인하고 클라이언트에 가상 인터페이스 생성 권한이 있는지 점검하세요.

TUN을 활성화할 때는 보통 장치 권한, 라우팅 제어와 DNS라는 세 가지 문제를 처리해야 합니다. 데스크톱 시스템에서는 관리자 권한 승인이 표시될 수 있고, Android는 시스템 VPN 권한으로 로컬 VPN을 구성합니다. Linux에서는 커널 모듈, capability 또는 root 권한이 필요할 수 있습니다. 라우팅 제어는 어떤 대상이 TUN으로 들어갈지 결정하며 auto-route, strict-route 등의 의미는 클라이언트와 커널 설정에 따라 다릅니다. DNS를 잘못 처리하면 도메인 해석이 로컬 네트워크로 빠져 규칙 판단과 실제 연결이 달라지거나 LAN 도메인이 해석되지 않을 수 있습니다.

6.1 권장 활성화 순서

먼저 불필요한 타사 VPN, 네트워크 가속기와 브라우저 프록시 확장을 끄고 여러 가상 인터페이스가 경쟁하지 않도록 하세요. 일반 시스템 프록시 모드에서 클라이언트 설정으로 테스트 대상에 접속할 수 있는지 확인한 뒤 TUN을 켜고 시스템 권한을 승인합니다. 활성화 후에는 LAN 게이트웨이, 일반 웹페이지와 프록시가 필요한 대상을 차례로 테스트하고 해석 가능 여부, 연결 로그와 규칙 매칭 변화를 각각 확인하세요. LAN만 작동하지 않는다면 LAN 규칙, 라우팅 제외와 DNS를 먼저 점검합니다. 모든 네트워크가 작동하지 않는다면 TUN을 끄고 시스템 프록시로 복구한 뒤 권한과 가상 인터페이스를 확인하세요.

모바일 기기에서 VPN 아이콘이 나타나는 것은 시스템 VPN이 구성되었다는 뜻일 뿐, 현재 설정의 노드가 사용 가능하다는 의미는 아닙니다. 앱별 프록시 기능으로 일부 앱이 VPN을 우회할 수 있고, 배터리 최적화 때문에 백그라운드에서 중지될 수도 있습니다. Android에서는 배터리 백그라운드 제한, 항상 켜진 VPN 옵션과 앱 분할 목록을 확인하세요. iOS의 네트워크 제어 범위는 앱이 제공하는 시스템 확장 기능에 따라 달라지므로 데스크톱 TUN 개념을 모바일에 그대로 적용해서는 안 됩니다.

6.2 DNS 동작과 fake-ip 판단하기

fake-ip 모드는 도메인에 가상 주소를 할당해 커널이 도메인 기준 규칙 처리를 계속할 수 있도록 하며, 안정적인 도메인 식별이 필요한 환경에 적합합니다. 그러나 일부 LAN 도메인, 로컬 프린터, 기업 내부망과 실제 주소에 의존하는 프로그램은 호환되지 않을 수 있습니다. 이런 문제가 발생하면 LAN 접미사, 사설 주소와 특정 도메인을 DIRECT 또는 fake-ip-filter에 추가할 수 있습니다. 구체적인 필드는 현재 설정과 클라이언트 문서를 기준으로 확인하세요. 하나의 LAN 기기 문제를 해결하려고 모든 DNS 처리를 끄지 말고 먼저 문제 범위를 좁히세요.

tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-filter:
    - "*.lan"
    - "*.local"

이 설정은 일반적인 필드 간 관계를 설명하기 위한 것이며 플랫폼에 필요한 전체 DNS 서버 목록을 대신하지 않습니다. stack, auto-route와 enhanced-mode의 사용 가능 여부는 현재 커널 지원 범위를 따라야 합니다. 설정을 수정한 뒤에는 먼저 문법을 확인하고 한 번에 하나의 필드만 변경하세요. 특정 플랫폼에서 TUN이 시작되지 않으면 클라이언트 설정에서 강화 모드를 끄고 시스템 프록시 경로로 돌아가 일상적인 사용을 이어갈 수 있습니다.

7. 일상적인 유지 관리, 문제 해결과 고급 학습 경로

안정적인 사용은 롤백 가능성, 관찰 가능성, 최소 변경이라는 세 가지 원칙에 달려 있습니다. 롤백 가능성이란 최근 정상 연결된 설정을 보관하는 것이고, 관찰 가능성이란 로그, 규칙 매칭과 시스템 프록시 상태를 확인할 위치를 아는 것입니다. 최소 변경은 매번 관련 설정 하나만 조정하는 것을 뜻합니다. 이 세 가지를 실천하면 대부분의 문제를 설정 해석, 시스템 트래픽 제어, 규칙 판단 또는 원격 연결 중 한 영역으로 좁힐 수 있어 클라이언트를 반복해서 재설치할 필요가 없습니다.

7.1 반복해서 적용할 수 있는 문제 해결 순서

첫째, 클라이언트 프로세스와 현재 설정을 확인합니다. 설정이 정상적으로 로드되지 않았다면 해석 가능한 이전 파일을 먼저 복원하세요. 둘째, 리스닝 포트를 확인하고 다른 프로그램이 포트를 사용 중인지 점검하며 애플리케이션이 HTTP, SOCKS 또는 혼합 포트 중 무엇을 사용하는지 확인합니다. 셋째, 요청이 클라이언트로 들어오는지 확인합니다. 연결 목록이나 로그에 기록이 전혀 없다면 노드를 먼저 변경하지 마세요. 넷째, 규칙 매칭과 정책 그룹 선택을 확인하고 DIRECT, REJECT, 프록시 그룹과 빈 그룹을 구분합니다. 다섯째, 그 다음에 노드 연결, DNS, TLS와 원격 서비스 상태를 점검합니다.

브라우저에 프록시 연결 실패가 표시되면 먼저 시스템 프록시 주소가 여전히 로컬 호스트와 올바른 포트를 가리키는지 확인하세요. 하나의 애플리케이션만 실패한다면 독립 프록시를 사용하는지, 자체 DNS를 활성화했는지 또는 방화벽에 차단되었는지 확인합니다. 모든 앱이 실패하지만 클라이언트 로그에 요청이 없다면 문제는 트래픽 제어 계층에 있습니다. 로그에 연결 거부가 표시되면 정책 그룹이나 노드 문제입니다. 연결이 수립된 뒤 인증서 또는 웹페이지 내용에 오류가 발생할 때 TLS, 시스템 시간, 인증서 체인과 대상 사이트 응답을 추가로 확인하세요.

7.2 설정 업데이트와 로그 관리

구독을 업데이트하기 전에 설정 이름과 현재 정책 그룹을 기록하고, 업데이트 후 그룹 이름, 노드 수와 규칙 상태를 비교하세요. 노드 수를 품질 지표로 삼지 말고 목록이 길어졌다고 설정이 반드시 좋아졌다고 판단하지도 마세요. 문제를 점검할 때는 로그 수준을 일시적으로 높일 수 있지만 확인이 끝나면 적절한 수준으로 되돌려 불필요한 파일 생성을 줄이세요. 데스크톱 클라이언트의 로그 저장 위치는 프로젝트마다 다릅니다. 같은 오류가 반복되면 시간, 대상과 오류 원인이 포함된 일부 기록만 복사하면 되며 전체 설정이나 계정 정보가 들어 있는 구독 주소를 업로드할 필요는 없습니다.

설정 파일에는 구독으로 생성된 민감한 내용이 포함될 수 있습니다. 로그를 공유하거나 도움을 요청하기 전에 구독 URL, 인증 정보, 노드 주소에서 불필요한 식별 정보와 로컬 경로를 제거하세요. 필드 이름, 규칙 순서, 포트 유형과 오류 문구는 구조를 이해하는 데 도움이 되므로 남겨도 되지만 전체 접근 주소를 공개해서는 안 됩니다. 구독 주소가 유출되었다고 의심되면 브라우저 기록만 삭제하지 말고 서버에서 새 주소를 발급하세요.

7.3 개인용 컴퓨터에서 고급 설정으로 나아가기

기본 사용을 익힌 뒤에는 다음 순서로 확장할 수 있습니다. 먼저 규칙 모드와 정책 그룹 참조를 익히고, 이어서 DNS와 fake-ip의 적용 범위를 이해한 다음 TUN, 라우팅과 LAN 제외를 학습하고, 마지막으로 라우터, 투명 게이트웨이 또는 서버 배포를 고려하세요. 각 단계는 이전 단계를 검증할 수 있을 때 진행해야 합니다. 복잡한 설정을 그대로 복사하면 여러 미지의 변수가 동시에 들어와 문제가 발생했을 때 커널 기능, 플랫폼 권한과 설정 문법 중 원인을 구분하기 어렵습니다.

라우터 배포에는 포워딩 경로, 게이트웨이 위치, DHCP, IPv6, 방화벽과 우회할 장치 범위도 고려해야 합니다. 커널의 리스닝 주소가 로컬 호스트에만 바인딩되어 있으면 LAN 기기가 접근할 수 없습니다. 반대로 신뢰할 수 없는 네트워크에 그대로 노출하면 관리 및 프록시 진입점이 확대됩니다. 서버를 운영할 때는 프로세스 감시, 로그 순환과 업그레이드 롤백을 설정해야 하며, 클라이언트 인터페이스의 ‘시스템 프록시’ 버튼은 라우터의 트래픽 포워딩 규칙을 대신할 수 없습니다. 이 영역은 먼저 격리된 환경에서 검증한 뒤 가정용 네트워크로 단계적으로 옮기는 것이 좋습니다.

7.4 문제 기록 템플릿

문제를 점검할 때마다 플랫폼, 클라이언트 이름, 현재 모드, TUN 활성화 여부, 설정을 방금 업데이트했는지, 대상 도메인, 로그의 오류 문구와 시도한 변경 한 가지를 기록하세요. 이런 기록은 ‘갑자기 안 돼요’보다 원인을 찾기 쉽고 같은 방법을 반복하는 것도 막아 줍니다. 더 확인할 내용이 필요하다면 먼저 자주 묻는 질문의 분류별 답변을 읽고 이 문서의 해당 장으로 돌아오세요. Windows UWP 루프백 제한, HTTPS 인증서 오류와 프록시 모드 차이 같은 구체적인 상황은 Windows UWP 앱이 Clash 프록시를 사용하지 못하는 문제 및 HTTPS 인증서 오류 문제 해결에서도 확인할 수 있습니다.

Clash의 설정 기능은 여러 계층이 결합되어 만들어집니다. 안정적인 사용의 핵심은 영원히 변하지 않는 템플릿을 외우는 것이 아니라 관찰하고 검증하는 습관을 갖는 것입니다. 먼저 기본 연결을 안정화한 뒤 규칙, DNS와 TUN을 단계적으로 추가하세요. 변경할 때마다 기록을 남기고 업데이트할 때마다 롤백 지점을 보관합니다. 설치 패키지가 필요하면 Clash 다운로드 페이지에서 플랫폼에 맞는 항목을 선택하고, 처음 설정한다면 빠른 시작 튜토리얼로 돌아가 기본 절차를 완료하세요.