Clash 입문부터 고급 설정까지

1. Clash 핵심 개념 이해하기

클라이언트·코어·서버의 역할

Clash는 일반적으로 프록시 코어를 기반으로 만들어진 클라이언트와 설정 생태계를 가리키며, 하나의 고정된 인터페이스를 뜻하지는 않습니다. GUI 클라이언트는 설정 가져오기, 시스템 프록시 전환, 노드 선택, 로그 표시를 담당하고, 코어는 로컬 포트에서 연결을 수신하고 규칙을 읽어 연결을 설정합니다. mihomo는 이 생태계에서 널리 쓰이는 코어 구현체입니다. 화면이 열렸다는 사실은 클라이언트가 실행되었다는 뜻일 뿐, 코어가 정상 작동하거나 원격 회선이 사용 가능하다는 증거는 아닙니다.

서버 노드는 실제로 트래픽을 전달하는 원격 진입점입니다. 클라이언트 설치 파일만으로 사용할 수 있는 노드가 생기지는 않으며, 구독은 프록시 프로토콜이 아니라 설정이나 노드 정보를 제공하는 방식입니다. 문제를 확인할 때는 세 가지를 나눠 보세요. 클라이언트가 설정을 관리하는지, 코어가 연결을 받는지, 노드가 원격 핸드셰이크를 완료하는지 확인해야 합니다. 모든 문제를 소프트웨어 설치 실패로 보면 실제 오류 지점은 그대로 둔 채 재설치만 반복하게 됩니다.

요청 하나로 살펴보는 전체 연결 흐름

앱이 요청을 보내면 트래픽은 시스템 프록시, 앱 자체 프록시 설정 또는 TUN을 통해 코어로 들어갑니다. 코어는 대상 도메인과 주소, 기타 조건에 따라 규칙을 선택한 뒤 연결을 직접 연결 정책이나 프록시 그룹으로 전달합니다. 프록시 그룹은 최종적으로 노드를 선택하고, 노드는 요청을 대상 서비스로 보냅니다. 응답은 반대 방향으로 돌아옵니다. 이 흐름에서 트래픽 진입점, 규칙 판정, 출구 노드는 서로 다른 계층입니다. 한 가지 기능을 켰다고 나머지 계층까지 올바르게 설정된 것은 아닙니다.

설정의 proxies는 노드를 정의하고, proxy-groups는 선택 관계를 구성하며, rules는 연결을 어떤 정책으로 보낼지 결정합니다. 규칙에서 참조하는 이름은 해당 노드, 프록시 그룹 또는 내장 정책에 실제로 정의되어 있어야 합니다. 이름이 비슷해도 서로 다른 이름일 수 있으며 대소문자, 공백, 문장 부호도 참조에 영향을 줄 수 있습니다. 익숙하지 않은 설정을 살펴볼 때는 첫 줄부터 필드를 외우기보다 진입 포트, 그룹 이름, 마지막 기본 규칙부터 찾는 편이 효과적입니다.

노드·정책·DNS 조회 결과 구분하기

노드 이름에 표시된 지역은 일반적으로 제공 업체가 붙인 표기일 뿐, 출구 IP가 해당 지역에 있다는 증거는 아닙니다. 지연 시간 측정 결과도 지정된 테스트 요청에 대한 값일 뿐 전체 다운로드 속도를 나타내지는 않습니다. 프록시 그룹은 노드를 선택하는 방법이지 또 다른 서버가 아닙니다. DNS는 도메인을 주소로 변환하며 규칙 매칭에도 영향을 줄 수 있습니다. 이 개념들을 구분해야 노드 전환, DNS 변경, 규칙 조정이 서로 다른 결과를 내는 이유를 이해할 수 있습니다. 모든 기능을 하나의 스위치처럼 취급하지 마세요.

이 설명서의 설정 블록은 특정 필드에 대한 예제입니다. 별도 안내가 없다면 완성된 구독 설정으로 가져오지 마세요. 기존 설정에는 노드와 클라이언트 전용 옵션이 포함될 수 있으므로 전체를 덮어쓰면 해당 내용이 사라집니다. 용어를 빠르게 확인하려면 용어 설명을 함께 참고하세요. 처음 연결을 설정하는 중이라면 사용 가이드의 순서에 따라 진행하면 됩니다. 먼저 작동하는 기본 구성을 만든 다음 고급 기능을 추가하면 변경 전후를 명확하게 비교할 수 있습니다.

2. 플랫폼에 맞는 클라이언트 선택하기

운영체제를 먼저 선택하고 사용 방식 확인하기

일반적인 데스크톱과 모바일 기기에서는 먼저 Clash Plus를 고려한 뒤 플랫폼과 사용 흐름에 따라 다른 클라이언트와 비교해 보세요. 선택 기준은 화면 모양이 아니라 운영체제 호환성, 설정 관리 방식, 필요한 프로토콜, 네트워크 제어 기능이어야 합니다. 설치 전에 다운로드 센터에서 플랫폼과 아키텍처를 확인하세요. 한 운영체제의 안내에 나온 버튼 이름을 다른 운영체제에 그대로 적용하면 안 됩니다. 규칙의 기본 개념은 공통으로 적용되지만 서비스 설치, 네트워크 권한, 백그라운드 실행 방식은 대체로 다릅니다.

Windows에서는 Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu를 비교해 볼 수 있습니다. Clash for Windows는 지원이 중단되었으므로 기존 환경을 참고하는 용도로만 살펴보고 새 기기의 기본 선택지로 삼지 않는 편이 좋습니다. macOS에서는 Clash Plus, Clash Verge Rev 또는 FlClash를 선택할 수 있습니다. ClashX Meta도 지원이 중단된 보관용 클라이언트로 보는 것이 적절합니다. 지원 상태와 현재 실행 가능 여부는 별개의 문제이므로 새 운영체제의 권한 체계와 이후 프로토콜 호환성을 특히 확인하세요.

Android에서는 Clash Plus, Clash Meta for Android, FlClash, Surfboard를 선택할 수 있습니다. Surfboard의 설정 형식은 Clash YAML과 다르므로 모든 클라이언트에서 같은 구독을 바로 사용할 수 있다고 가정하면 안 됩니다. iOS에서는 먼저 Clash Plus의 스토어 안내를 확인하세요. 공식 사이트는 clashplus.io입니다. Linux 데스크톱에서는 Clash Verge Rev 또는 FlClash를 고려할 수 있고, GUI가 없는 서버와 라우터에는 mihomo를 별도로 배포하는 편이 적합합니다.

기능을 비교할 때 실제 사용 코어 확인하기

프로토콜 지원을 확인할 때는 클라이언트가 실제로 사용하는 코어와 구독 필드를 함께 확인해야 합니다. 화면에 어떤 프로토콜 이름이 표시된다고 해서 현재 코어가 제공 업체의 모든 매개변수를 해석할 수 있다는 뜻은 아닙니다. 가져오기 오류가 발생하면 오류가 난 필드와 클라이언트 이름을 기록해 두세요. 소프트웨어 아이콘만 기록하는 것보다 문제 파악에 도움이 됩니다. 호환성 테스트를 위해 여러 프록시 코어를 동시에 실행하지 마세요. 포트, 시스템 프록시, 가상 네트워크 어댑터를 서로 차지하려다 정상적인 설정까지 작동하지 않을 수 있습니다.

시스템 아키텍처에 따라 설치 파일의 실행 가능 여부가 달라집니다. Apple Silicon과 Intel 기기는 각각에 맞는 빌드를 선택하고, Windows와 Linux도 프로세서 아키텍처를 확인해야 합니다. Android용 ARM64와 ARM 설치 파일은 서로 바꿔 쓸 수 없습니다. 확인하기 어렵다면 기기 정보와 다운로드 페이지의 설명을 먼저 살펴보세요. 설치 실패는 최소 시스템 요구 사항이나 설치 경로 제한 때문일 수도 있습니다. 이런 문제는 네트워크 전달 과정에 앞서 발생하므로 처음부터 프록시 설정을 수정하지 마세요.

클라이언트를 정했으면 먼저 한 앱에서 기본 연결을 설정하고, 그다음 이전 클라이언트에서 옮길지 판단하세요. 이전할 때는 기존 설정 파일, 구독 출처, 필요한 프록시 그룹 선택 기록을 보존해야 합니다. 화면에 표시된 노드 이름만 복사해서는 안 됩니다. 플랫폼별 후보를 나란히 비교하려면 클라이언트 비교를 확인하세요. 이전을 마친 뒤에는 다음 재부팅 때 두 프로그램이 다시 네트워크를 제어하지 않도록 기존 클라이언트의 자동 시작과 시스템 프록시를 해제하세요.

3. 클라이언트 설치 및 포트 확인하기

최소한의 실행 환경 구성하기

다운로드 센터에서 운영체제와 아키텍처에 맞는 설치 파일을 받아 시스템 안내에 따라 설치하세요. 처음 실행하면 설정 페이지, 코어 상태, 로그 위치를 먼저 확인하고 시스템 프록시, TUN, LAN 공유, 복잡한 덮어쓰기를 한꺼번에 켜지 마세요. 우선 클라이언트가 코어를 실행하고 실제 설정 파일 위치를 찾는지 확인해야 합니다. 네트워크 확장 기능이나 서비스 권한이 필요하다면 시스템 안내를 확인한 후 허용하세요. 실행을 시도하려고 보안 알림을 반복해서 끄지 마세요.

데스크톱 클라이언트는 GUI와 백그라운드 서비스를 따로 실행할 수 있습니다. 창을 닫아도 코어가 중지되지 않을 수 있고, 트레이 아이콘을 종료해도 백그라운드 서비스가 남아 있을 수 있습니다. 설치 전후에 다른 프록시 프로그램이 실행 중인지 확인하세요. 포트가 사용 중이라는 안내가 나오면 먼저 어떤 프로세스가 점유하고 있는지 확인하세요. 네트워크 관련 프로세스를 무작정 모두 종료하지 마세요. 모바일에서 VPN 권한을 요청하면 방금 설치한 클라이언트에 대한 권한인지 확인하세요. 일반적으로 시스템 VPN 연결 지점은 한 번에 하나의 세션만 사용할 수 있다는 점도 유의해야 합니다.

로컬 포트와 노드 포트는 다릅니다

mixed-port는 기기의 앱이 코어에 연결하는 진입점이며 HTTP와 SOCKS 프록시 요청을 모두 받을 수 있습니다. 노드의 서버 포트는 구독에 정의된 노드 항목에 있으며 용도가 다릅니다. 다음 예제는 현재 기기에서만 사용할 수 있도록 로컬 진입점을 루프백 주소로 제한합니다. 포트 번호는 설정 예시일 뿐 모든 클라이언트의 기본값이 아닙니다. 앱에 프록시 주소를 입력할 때는 클라이언트에 현재 표시된 수신 포트를 기준으로 해야 합니다.

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

브라우저나 도구에서 로컬 프록시를 사용할 때 주소에는 보통 127.0.0.1을 입력하고 포트에는 코어의 실제 수신 포트를 입력합니다. 원격 노드 주소를 여기에 입력하면 안 됩니다. 같은 LAN의 다른 기기에서도 프록시를 사용해야 한다면 수신 주소, 접근 인증, 방화벽 범위를 별도로 검토하세요. allow-lan을 켜는 것만으로 설정이 끝나는 것은 아닙니다. 외부에 공개된 프록시 진입점은 다른 기기에서 사용할 수 있으며 회선 트래픽을 소모할 수 있습니다.

시작 로그로 서비스 상태 확인하기

Windows에서는 PowerShell에서 Get-NetTCPConnection -LocalPort 7890 -ErrorAction SilentlyContinue을 실행해 예시 포트의 수신 및 연결 정보를 확인할 수 있습니다. Linux에서는 ss -lntp로 수신 중인 프로세스를 확인하세요. 결과가 비어 있다면 코어가 실행 중인지, 클라이언트에서 포트가 변경되지 않았는지도 확인해야 합니다. 수신 기록이 나타나더라도 어떤 프로세스인지 확인하세요. 해당 포트를 사용하는 프로세스가 있다는 이유만으로 현재 클라이언트가 수신 중이라고 단정할 수 없습니다.

코어가 시작된 직후 종료된다면 로그에서 첫 번째 설정 오류를 먼저 확인하세요. 이후 발생하는 연결 거부는 시작 실패에 따른 연쇄 오류일 수 있습니다. 흔한 원인은 YAML 들여쓰기, 중복 필드, 설정 파일 읽기 실패, 그룹 이름 참조 오류입니다. 문제를 하나 수정한 뒤 다시 불러와 새로 나타난 첫 오류를 확인하세요. 한 번에 많은 필드를 바꾸지 마세요. 시스템 권한 문제는 구독 파일에 관련 없는 매개변수를 추가하지 말고 클라이언트의 서비스 관리 메뉴에서 처리하세요.

설치가 끝났는지 확인하려면 코어가 계속 실행되고, 현재 포트를 사용하는 프로세스가 명확하며, 로그에서 반복적인 재시작이 없고, 기존의 일반 인터넷 연결도 작동해야 합니다. 이때 설정 디렉터리 위치와 시작 방법을 저장해 두고 다음 장에서 구독을 가져오세요. 클라이언트를 종료한 뒤 네트워크에 문제가 생기면 시스템 프록시가 중지된 로컬 포트를 계속 가리키는지 먼저 확인하세요. 프록시를 해제해 직접 연결을 복구한 다음 설치 문제를 살펴보면 남은 프록시 설정을 시스템 네트워크 전체의 장애로 오해하지 않을 수 있습니다.

4. 구독 가져오기 및 설정 관리하기

구독에서 제공하는 항목부터 확인하기

구독 주소는 완성된 Clash YAML을 반환할 수도 있고 노드 목록이나 다른 형식을 반환할 수도 있습니다. 완성된 설정에는 보통 노드, 프록시 그룹, 규칙이 포함되며 가져온 뒤 선택 가능한 Profile로 사용할 수 있습니다. 노드 목록만 제공되는 경우에는 기본 설정에 provider를 추가해야 사용할 수 있습니다. Base64는 인코딩 방식일 뿐 호환성을 보장하지 않습니다. 가져오기 전에 제공 업체가 어떤 형식을 지원하는지 확인하세요. 브라우저에서 링크가 열리는지만 확인해서는 안 됩니다.

클라이언트의 설정 또는 구독 페이지에서 원격 설정을 추가하고 전체 주소를 붙여 넣어 저장하세요. 다운로드가 끝나면 해당 설정을 현재 설정으로 선택합니다. 항목만 추가하고 활성화하지 않는 실수도 흔합니다. 활성화한 뒤 프록시 그룹이 표시되는지, 그룹을 펼쳤을 때 노드가 비어 있지 않은지 확인하세요. 클라이언트에 다운로드 및 업데이트 시간이 표시된다면 마지막 성공 상태를 기록해 두세요. 새로고침 버튼을 눌렀다는 사실만으로 서버의 내용이 정상적으로 교체되었다고 판단하지 마세요.

구독 주소에는 계정 정보가 포함될 수 있으므로 중요한 인증 정보처럼 보관하세요. 화면을 공유할 때는 전체 주소를 가리고, 로그를 다른 사람에게 전달하기 전에 쿼리 매개변수와 인증 필드를 삭제하세요. 개인 구독 주소를 잘 모르는 온라인 변환 사이트에 붙여 넣지 마세요. 변환 서비스에서 주소와 노드 내용을 읽을 수 있습니다. 형식을 변환해야 한다면 제공 업체가 공식 지원하는 출력 방식을 우선 사용하거나, 통제된 환경에서 변환한 뒤 결과를 확인하세요.

로컬 수정과 원격 업데이트 구분하기

원격 설정의 원본 파일은 다음 업데이트 때 교체될 수 있으므로 직접 편집한 규칙이 유지되지 않을 수 있습니다. 클라이언트의 덮어쓰기, 병합, 확장 설정 기능을 사용하면 로컬 변경 사항을 저장할 수 있지만 병합 순서는 클라이언트마다 다릅니다. 사용하기 전에 배열 전체를 바꾸는지, 항목을 추가하는지 확인하고 최종 적용 설정을 살펴보세요. 편집기에 규칙이 보인다고 해서 코어가 현재 읽는 파일에도 반영되었다고 단정할 수는 없습니다.

다음은 provider 호환 콘텐츠를 제공하는 경우에만 사용할 수 있는 mihomo 원격 노드 목록 예제입니다. 예시 도메인은 구조를 설명하기 위한 것으로 실제 노드를 제공하지 않습니다. 사용하려면 유효한 주소로 바꿔야 합니다. 기본 설정에는 해당 provider를 참조하는 프록시 그룹도 정의해야 합니다. 일반적인 완성형 구독을 다운로드할 때는 직접 여러 파일로 나누지 말고 클라이언트의 원격 설정 메뉴를 사용하세요.

proxy-providers:
  remote:
    type: http
    url: "https://example.com/proxies.yaml"
    path: ./providers/remote.yaml
    interval: 3600

proxy-groups:
  - name: PROXY
    type: select
    use:
      - remote

업데이트 실패 및 여러 설정 전환하기

구독 업데이트에 실패하면 먼저 다운로드 실패인지 파싱 실패인지 구분하세요. 다운로드 실패라면 현재 네트워크, 구독의 유효성, 아직 작동하지 않는 프록시에 요청이 잘못 의존하고 있는지 확인합니다. 파싱 실패라면 응답이 웹페이지, 로그인 안내 또는 호환되지 않는 형식인지 살펴보세요. API에서 반환된 오류 페이지를 YAML로 저장한 뒤 들여쓰기만 계속 수정하지 마세요. 이전에 사용하던 설정을 보존하면 업데이트 실패 시 명확하게 되돌아갈 수 있습니다.

여러 설정을 사용할 때는 용도별로 이름을 붙이고 출처, 호환 클라이언트, 로컬 확장 위치를 기록하세요. 설정을 전환하면 프록시 그룹 이름이 바뀔 수 있어 이전에 선택한 노드가 유지되지 않을 수 있습니다. 현재 모드와 기본 그룹을 다시 확인하세요. 자동 업데이트 주기는 제공 업체의 요구 사항에 맞추면 되며 자주 수동으로 새로고침할 필요는 없습니다. 형식별 차이는 구독 URL·YAML·Base64 안내에서, 여러 설정을 정리하는 방법은 Profile 관리 방법에서 확인하세요.

5. 프록시 모드 선택 및 연결 확인하기

모드는 정책을 결정하며 트래픽 진입점을 정하지 않습니다

규칙 모드는 설정에 있는 규칙을 차례로 적용해 트래픽의 경로를 결정하며 일상적인 분할에 적합합니다. 전역 모드는 코어에 들어온 프록시 트래픽을 보통 전역 선택기로 전달하고, 직접 연결 모드는 코어에 들어온 트래픽에 직접 연결 정책을 적용합니다. 이 세 모드는 코어가 이미 받은 연결을 어떻게 처리할지 결정합니다. 앱이 시스템 프록시를 사용하지도 않고 TUN으로 연결되지도 않는다면 규칙 모드나 전역 모드로 바꿔도 앱의 트래픽이 자동으로 코어에 들어오지 않습니다. 문제를 확인할 때 가장 먼저 살펴봐야 할 부분입니다.

시스템 프록시는 운영체제가 앱에 제공하는 프록시 설정이며 모든 네트워크 연결을 강제로 제어하지는 않습니다. 일부 앱은 이 설정을 따르지만, 자체 프록시 설정을 사용하는 앱도 있고 네트워크에 직접 연결하는 앱도 있습니다. 먼저 시스템 프록시를 지원하는 브라우저에서 확인한 뒤 다른 앱으로 범위를 넓혀 보세요. 게임이나 명령줄 도구가 프록시를 사용하지 않는다고 해서 시스템 프록시가 작동하지 않는다고 단정하지 마세요. 해당 앱이 애초에 이 설정을 읽지 않을 수 있습니다.

진입점·규칙·출구 순서로 확인하기

설정을 가져온 뒤 주요 프록시 그룹에서 노드를 하나 선택하고 시스템 프록시를 켠 다음 브라우저에서 새 요청을 보내세요. 연결 패널에 대상 도메인이 표시되는지, 적용된 규칙과 정책 경로가 예상과 일치하는지 확인합니다. 기존 연결은 이전 경로를 계속 사용할 수 있으므로 노드를 바꾼 뒤에는 새 연결을 만들어 확인하세요. 로그에 해당 요청이 전혀 없다면 원격 노드 매개변수를 먼저 수정하지 말고 앱 진입점과 프록시 포트를 확인하세요.

명령줄에서는 다음과 같이 로컬 HTTP 프록시를 명시적으로 지정할 수 있습니다. 예시 포트는 실제 설정과 일치해야 하며 대상 서비스에도 접속할 수 있어야 합니다. HTTP 응답을 받았다는 것은 해당 요청이 지정된 진입점을 통해 처리되었다는 뜻일 뿐입니다. 실제로 원격 노드를 사용했는지는 규칙과 연결 기록에서 확인해야 합니다. 규칙이 DIRECT를 선택했다면 명령에서 로컬 프록시 진입점을 사용했더라도 출구는 현재 네트워크의 직접 연결일 수 있습니다.

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

웹사이트를 테스트할 때는 연결 여부, 출구 IP, 서비스 사용 가능 여부를 구분하세요. 페이지가 열린다고 해서 모든 리소스가 같은 경로로 전송되는 것은 아니며 출구 IP가 바뀌어도 특정 서비스를 반드시 사용할 수 있는 것은 아닙니다. 서비스 제공 업체는 계정, 지역, 기기, 서비스 정책에 따라 접근을 제한할 수 있습니다. 노드를 선택할 때 먼저 연결이 성립하는지 확인한 다음 실제 서비스 동작을 비교하세요. 지연 시간과 배율을 판단하는 방법은 Clash 노드 선택 방법에서 확인할 수 있습니다.

Windows UWP 루프백 및 앱 예외 설정

일부 Windows 샌드박스 앱은 네트워크 격리 때문에 로컬 루프백 프록시에 연결하지 못할 수 있습니다. 앱이 시스템 프록시를 사용하고 브라우저 테스트는 정상인데 연결이 코어에 들어오지 않는 경우에만 UWP 루프백 예외를 검토하세요. 클라이언트에서 루프백 관리 도구를 제공한다면 필요한 앱에만 권한을 부여하고 모든 앱을 일괄 변경하지 마세요. 루프백 예외는 로컬 진입점의 접근 제한을 해결하는 기능이지, 구독 만료나 노드 시간 초과, 잘못된 규칙을 해결하지는 않습니다.

앱에 별도의 프록시 설정이 있다면 시스템 설정과 충돌하는지 확인하세요. 클라이언트를 종료하기 전에 시스템 프록시를 끄면 중지된 포트에 계속 연결하는 상황을 피할 수 있습니다. 전역 모드에서는 서비스가 작동하지만 규칙 모드에서 실패한다면 두 모드의 정책 경로를 기록한 뒤 규칙 장에서 원인을 찾아보세요. 명시적 프록시 테스트에서 모든 노드가 실패한다면 먼저 노드와 네트워크를 확인해야 합니다. 첫 연결 점검에는 연결 확인 체크리스트를 참고하세요. 스위치 색상 하나만 보고 결론 내리지 마세요.

6. Clash 사용자 지정 규칙 작성하기

위에서부터 확인하며 먼저 일치하는 규칙 적용하기

규칙 목록에는 순서가 있으므로 조건을 무작위로 모아 놓은 집합이 아닙니다. 코어는 일반적으로 위에서 아래로 규칙을 확인하고 일치하는 규칙을 찾으면 해당 정책을 선택합니다. 따라서 더 구체적인 예외를 포괄적인 규칙보다 앞에 두고 마지막에 기본 규칙을 배치해야 합니다. MATCH가 나머지 모든 연결을 처리하면 그 뒤에 있는 일반 규칙은 해당 연결에 적용될 기회가 없습니다. 트래픽 분할을 수정할 때는 구문이 올바른지만 보지 말고 규칙의 위치와 정책 이름도 확인하세요.

DOMAIN은 도메인 전체 이름을 정확히 일치시키고, DOMAIN-SUFFIX는 도메인 접미사를 기준으로 일치시킵니다. IP-CIDR은 IP 주소 대역에, GEOIP는 IP의 지리 정보에 따라 적용됩니다. 도메인 규칙을 적용하려면 코어가 해당 도메인 정보를 확보해야 하며, IP 규칙은 대상 주소와 관련 데이터에 의존합니다. 도메인 규칙 하나로 모든 접속 방식을 처리할 수는 없습니다. 특히 앱이 IP에 직접 요청하거나 별도의 DNS를 사용하거나 연결을 재사용하는 경우에는 연결 패널에서 실제 대상을 확인해야 합니다.

좁은 범위의 예외로 규칙 순서 검증하기

다음 예제는 문서 도메인을 직접 연결하고 코드 호스팅 도메인은 PROXY로 보낸 다음 중국 IP 주소와 나머지 트래픽을 처리합니다. PROXY는 실제 설정에 정의되어 있어야 합니다. IP 대역 규칙의 no-resolve는 해당 주소 일치에 필요한 추가 도메인 조회를 방지하는 옵션이지 설정 전체의 DNS를 끄는 기능이 아닙니다. 이 예제는 순서를 설명하기 위한 것이므로 현재 네트워크에 적합한지는 실제 용도에 따라 하나씩 확인해야 합니다.

rules:
  - DOMAIN,example.com,DIRECT
  - DOMAIN-SUFFIX,github.com,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

규칙을 추가한 뒤 설정을 다시 불러오고 새 연결을 만들어 보세요. 적용된 규칙, 대상 도메인, 최종 프록시 그룹을 확인해 변경 사항이 실행 중인 설정에 반영되었는지 점검합니다. 앞부분의 규칙이 적용된다면 순서를 조정하거나 상위 규칙의 조건을 좁히세요. 계속 도메인이 아니라 IP 주소만 표시된다면 앱의 DNS 처리 방식과 DNS 연결 흐름을 확인하세요. 여러 도메인을 함께 사용하는 서비스라면 메인 페이지 규칙만 추가하지 말고 로그인, API, 리소스 도메인의 연결도 살펴보세요.

규칙 모음과 로컬 덮어쓰기의 범위

규칙이 늘어나면 rule-providers로 규칙 모음을 참조하고 rules에서 RULE-SET을 사용할 수 있습니다. 규칙 모음의 유형은 실제 내용과 일치해야 하므로 도메인 목록, IP 주소 목록, 클래식 규칙을 임의로 섞어 사용할 수 없습니다. 원격 규칙 모음 업데이트에 실패하면 코어가 기존 캐시를 계속 사용할 수 있습니다. 화면에 규칙 모음이 표시된다고 해서 방금 다운로드에 성공했다는 뜻은 아닙니다. 업데이트 시간, 로그, 실제 연결에 적용된 규칙을 함께 확인하세요.

구독 규칙과 로컬 규칙을 병합할 때는 최종 규칙 순서가 가장 중요합니다. 덮어쓰기 기능에 따라 rules 배열 전체를 교체하기도 하고 앞이나 뒤에 항목을 삽입하기도 합니다. MATCH 뒤에 예외를 추가하면 대개 원하는 대로 작동하지 않습니다. 장기적으로 관리하려면 로컬 규칙을 필요한 개인 차이만 남기고 추가 이유를 기록하세요. 외부 규칙 전체를 복사하면 조건이 중복되거나 분류가 오래될 수 있으며, 문제가 생겼을 때 어느 계층을 수정해야 하는지도 파악하기 어렵습니다.

규칙을 테스트할 때는 직접 연결되어야 하는 요청과 프록시를 사용해야 하는 요청을 각각 포함하세요. 한 사이트의 문제를 해결하다 다른 서비스에 영향을 주는 상황을 방지할 수 있습니다. REJECT를 선택할 때는 차단 대상이 로그인에 필요한 연결이 아니라 실제 차단하려는 연결인지 확인하세요. 설정을 공유하기 전에 개인 도메인과 내부 네트워크 구조를 삭제해야 합니다. 자주 쓰는 매칭 방식에 익숙해진 후 프로세스 규칙처럼 플랫폼에 따라 달라지는 조건을 시도하세요. 운영체제마다 프로세스 식별 지원과 권한 요구 사항이 다르므로 한 기기에서 성공한 결과를 모든 플랫폼에서 보장된다고 볼 수 없습니다.

7. TUN 및 DNS 설정하기

TUN 연결과 시스템 프록시의 차이

TUN은 가상 네트워크 인터페이스와 라우팅으로 트래픽을 받아 시스템 프록시를 따르지 않는 일부 앱까지 처리할 수 있지만 노드를 빠르게 만드는 기능은 아닙니다. TUN을 켜면 트래픽 진입점과 DNS 경로가 달라지므로 일반 프록시가 작동하는 것을 확인한 뒤 활성화해야 합니다. 운영체제에 따라 백그라운드 서비스, 관리자 권한, 네트워크 확장 권한이 필요할 수 있으며 모바일에서는 보통 시스템 VPN 인터페이스를 사용합니다. 사용할 수 있는 필드는 클라이언트가 채택한 코어와 설정 메뉴에 따라 달라집니다.

비슷한 라우팅을 제어하는 다른 VPN이나 TUN 프로그램이 실행 중인지 먼저 확인한 뒤 클라이언트의 TUN을 켜세요. 활성화 전 로컬 네트워크, 내부 도메인, 주요 서비스가 작동하는지 기록하고 하나씩 비교합니다. 기업 VPN, 가상 머신의 네트워크 대역, 원격 관리 연결은 자동 라우팅과 충돌할 수 있습니다. 유일한 원격 세션에서 바로 라우팅 제어 방식을 바꾸지 말고 로컬 콘솔이나 별도의 복구 경로를 마련하세요. 관리 연결이 끊길 수 있습니다.

DNS를 전체 연결 흐름으로 살펴보기

DNS는 서버 주소 하나만 설정하는 문제가 아닙니다. 누가 조회를 시작하는지, 어떤 경로로 요청을 보내는지, 응답을 앱에 어떻게 전달하는지, 규칙에서 언제 조회 결과를 사용하는지까지 포함합니다. fake-ip 모드는 도메인에 매핑용 가상 주소를 할당한 뒤 코어에서 실제 대상을 연결합니다. 이 가상 주소는 노드의 출구 주소가 아닙니다. 일부 내부 서비스나 기기 검색 기능에서 실제 주소가 필요하다면 모든 도메인에 매핑을 끄기보다 실제 문제에 맞게 예외를 설정하세요.

다음은 TUN 연결과 내장 DNS의 관계를 보여주는 mihomo 학습 예제입니다. DNS 수신 주소는 로컬 루프백으로 제한되어 있으며 예시 업스트림에 연결할 수 있는지는 현재 네트워크에 따라 달라집니다. 기존 노드와 규칙, 클라이언트에 필요한 설정을 보존한 상태에서 병합해야 합니다. 화면에서 DNS와 TUN을 이미 관리할 수 있다면 먼저 화면에서 설정한 뒤 최종 설정을 확인하세요. 같은 필드를 여러 곳에서 반복해서 덮어쓰지 않도록 주의해야 합니다.

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1

dns-hijack의 포트 설정은 해당 전통 DNS 요청을 대상으로 하며 모든 암호화 DNS 연결을 자동으로 처리한다는 뜻은 아닙니다. 브라우저나 앱이 자체 암호화 DNS를 사용하면 도메인 정보가 보이는 방식과 규칙 판정 조건이 달라질 수 있습니다. 문제를 확인할 때는 이 설정을 기록하고, 일시적으로 DNS 경로를 통일해 결과를 비교하세요. DNS 업스트림에 프록시가 필요하다면 노드의 DNS 조회가 아직 연결되지 않은 동일한 프록시 경로에 의존하지 않는지도 확인해야 합니다.

증상에 따라 되돌리고 여러 계층을 한꺼번에 바꾸지 않기

TUN을 켠 뒤 모든 앱의 연결이 끊기면 먼저 TUN을 끄고 기존 시스템 프록시 구성이 복구되는지 확인한 다음 라우팅, 권한, 로그를 살펴보세요. 도메인 접속만 실패하고 IP 주소로는 접속할 수 없다면 DNS를 중점적으로 확인합니다. 내부 서비스만 실패하면 사설 네트워크 경로와 내부 DNS를 확인하세요. 특정 앱만 이상하다면 해당 앱의 프로토콜과 연결 경로를 살펴보세요. 한 번에 한 계층만 조정해야 어떤 변경으로 문제가 해결됐는지 알 수 있습니다.

TUN을 중지한 뒤 가상 인터페이스, 라우팅, 시스템 DNS가 정상 상태로 돌아왔는지 확인하세요. 웹페이지가 열린다고 백그라운드 앱의 기존 연결 문제를 무시하지 마세요. 여러 네트워크 제어 도구를 겹쳐 실행해 임시로 문제를 덮으려 하지도 마세요. 제대로 확인하려면 일반 웹페이지, 시스템 프록시를 사용하지 않는 앱, 내부 네트워크 접속, 절전 모드에서 깨어난 뒤의 재연결을 모두 테스트해야 합니다. 브라우저 프록시만 필요하다면 시스템 프록시 방식으로 충분합니다. 고급 옵션을 켜기 위해 관리 범위를 넓힐 필요는 없습니다.

8. 설정 관리 및 문제 해결

언제든 되돌릴 수 있는 기본 설정 유지하기

일상적인 관리의 목표는 현재 사용 중인 설정을 파악하고 변경에 실패했을 때 복구할 수 있도록 하는 것입니다. 최소한 클라이언트 이름, 코어 출처, 현재 Profile, 로컬 진입 포트, 덮어쓰기 위치를 기록하세요. 백업할 때는 원격 원본 설정과 개인 확장을 구분하고 구독에서 다시 받을 수 없는 규칙은 반드시 보관해야 합니다. 백업 파일에는 노드 인증 정보와 구독 주소가 들어 있을 수 있으므로 접근을 통제할 수 있는 위치에 저장하세요. 공개 코드 저장소에 올리거나 문제 해결을 위해 아무에게나 보내지 마세요.

클라이언트 업데이트, 코어 업데이트, 구독 업데이트는 서로 별개의 변경입니다. 클라이언트를 업데이트하면 서비스 관리와 병합 방식이 달라질 수 있고, 코어 업데이트는 지원 필드에 영향을 줄 수 있으며, 구독 업데이트는 노드, 그룹 이름, 규칙을 바꿀 수 있습니다. 문제가 생기면 가장 최근에 어느 계층을 변경했는지 먼저 확인하세요. 문제를 해결하는 동안 클라이언트 업그레이드, 구독 교체, DNS 변경을 동시에 진행하지 마세요. 네트워크가 복구되더라도 원인을 설명하거나 안정적인 설정을 재현하기 어려워집니다.

인터넷 연결 문제를 구체적인 증상으로 나누기

연결 기록이 전혀 없다면 먼저 앱이 로컬 진입점에 연결되는지, 시스템 프록시가 올바른 포트를 가리키는지 확인하세요. 기록은 있지만 노드 연결이 시간 초과된다면 노드 상태, 원격 주소 접근성, 현재 네트워크의 제한을 중점적으로 살펴보세요. 도메인 조회 실패가 표시되면 DNS 요청과 노드 주소 조회를 확인해야 합니다. HTTP 오류 응답이 명확하게 돌아왔다면 특정 서비스까지 연결되었을 수 있습니다. 프록시 인증 오류, 대상 서비스의 거부, 계정 사용 제한을 구분해 확인하세요.

네트워크를 전환하거나 절전 모드에서 깨어난 뒤 이전 연결이 더 이상 유효하지 않은 인터페이스를 사용하고 있을 수 있습니다. 먼저 새 요청을 보내고 그다음 코어를 재시작하세요. 설정을 바로 삭제할 필요는 없습니다. 공용 네트워크에서 웹페이지 인증이 필요하다면 먼저 네트워크 접속 인증을 완료한 뒤 프록시를 다시 켜세요. 그렇지 않으면 구독 업데이트와 노드 테스트가 함께 실패해 모든 회선을 갑자기 사용할 수 없는 것처럼 보일 수 있습니다. 모바일 기기에서는 백그라운드 실행 제한 때문에 화면이 잠긴 뒤 클라이언트 프로세스나 네트워크 세션이 중지되는지도 확인하세요.

로그는 문제를 파악할 만큼만 기록하고 범위를 제한하기

평소에는 정보 수준 로그를 사용하고 문제가 있을 때만 잠시 상세도를 높인 다음 한 번 재현하고 원래 설정으로 되돌리세요. 상세 로그를 계속 많이 기록하면 디스크 쓰기가 늘고 도메인, 경로, 연결 메타데이터가 저장될 수도 있습니다. 문제를 신고할 때는 조작 순서, 운영체제, 오류 발생 시각, 관련 로그 몇 줄을 첨부하면 됩니다. 구독 정보, 인증 정보, 개인 네트워크 정보는 삭제하세요. 진입점, 정책, 오류 유형 없이 “연결이 안 됩니다”라고만 하면 실제 조치를 판단하기 어렵습니다.

노드 테스트는 성공했는데 실제 서비스가 작동하지 않는다면 같은 서비스를 대상으로 비교하고 해당 서비스에서 UDP, 여러 도메인, 별도 DNS를 사용하는지 확인하세요. 테스트 주소와 실제 서비스는 서로 다른 대상이므로 결과가 달라도 이상한 일이 아닙니다. 규칙 문제를 가리기 위해 전역 모드를 계속 사용하지 마세요. 경로를 잠시 비교하는 용도로는 쓸 수 있지만 마지막에는 필요한 모드로 되돌리고 관련 조건을 수정해야 합니다. 내부망, 업데이트 서비스, 다른 앱의 경로가 의도치 않게 바뀔 수 있습니다.

관리 작업이 끝나면 더 이상 필요하지 않은 디버그 기능을 끄고 중복된 자동 시작 항목을 정리한 다음 클라이언트 종료 시 시스템이 예상한 상태로 돌아오는지 확인하세요. 어떤 증상 때문에 어떤 규칙을 바꿨고 어떻게 확인했는지 짧게 기록해 두세요. 비슷한 문제가 다시 생겼을 때는 이 기록을 먼저 살펴보고 익숙하지 않은 설정 전체를 다시 복사하지 마세요. 안정적인 설정의 가치는 필드가 많은 데 있는 것이 아니라 각 변경에 확인할 수 있는 이유와 결과가 있는 데 있습니다.

9. 검증 가능한 고급 설정 단계 만들기

단일 기기 설정에서 관리 가능한 구성으로

앞선 8개 장을 마친 뒤에는 명확한 필요에 따라 고급 설정을 진행하세요. 노드를 자주 바꾼다면 프록시 그룹의 선택 방식을 알아보고, 규칙을 반복해서 관리한다면 규칙 모음을 살펴보세요. 서비스를 상시 실행해야 한다면 명령줄과 서비스 관리를 익히면 됩니다. 외부 설정 파일의 모든 필드를 자신의 환경에 복사하지 마세요. 라우터에서 유용한 옵션이 모바일 기기에도 적합한 것은 아닙니다. 필요한 조건과 권한, 복구 방법부터 확인해야 합니다.

프록시 그룹의 select는 직접 선택할 때 적합하며 url-test는 지정한 테스트 결과를 바탕으로 후보 노드를 비교하고 fallback은 사용 가능 여부와 순서에 따라 선택합니다. 자동 선택이 실제 서비스 품질을 보장하지는 않습니다. 테스트 요청이 성공해도 모든 대상 서비스가 작동한다는 뜻은 아닙니다. 설정할 때 테스트 주소, 확인 주기, 후보 범위를 명확히 지정하고 순위를 보기 위해 테스트를 지나치게 자주 실행하지 마세요. 서비스 이용 지역을 안정적으로 유지해야 한다면 자동으로 자주 전환하기보다 적절한 회선을 수동으로 고정하는 편이 나을 수 있습니다.

명령줄 배포는 검증한 뒤 상시 실행하기

GUI가 없는 Linux 환경에서는 먼저 포그라운드에서 설정을 검증하고 로그와 파일 경로를 확인한 다음 systemd 등의 서비스 관리 방식에 연결하세요. 프로그램의 작업 디렉터리와 설정 디렉터리를 혼동하지 말아야 하며 규칙 모음의 상대 경로도 안정적인 위치를 가리켜야 합니다. 다음 명령은 mihomo가 실행 경로에 있고 현재 디렉터리에 완성된 설정 파일이 있다고 가정합니다. 구문 검사에 통과해도 설정을 읽을 수 있다는 뜻일 뿐 노드, DNS, 대상 서비스에 연결할 수 있다는 보장은 아닙니다.

mihomo -t -d ./mihomo-data -f ./config.yaml
mihomo -d ./mihomo-data -f ./config.yaml

포그라운드에서 정상 실행되는 것을 확인한 뒤 시스템 규칙에 맞춰 서비스 사용자, 작업 디렉터리, 설정 경로, 재시작 정책을 지정하세요. 모든 작업에 기본 관리자 계정을 사용하지 마세요. TUN에 특정 네트워크 권한이 꼭 필요하다면 배포 환경에 필요한 권한만 부여해야 합니다. 서비스 로그를 살펴볼 때 프로세스 종료와 네트워크 요청 실패를 구분하세요. 잘못된 설정으로 무한 재시작을 반복해도 저절로 해결되지 않습니다. 데스크톱과 명령줄 배포의 차이는 Linux에서 Clash를 배포하는 두 가지 방법을 참고하세요.

관리 인터페이스와 네트워크 공유를 별도로 검토하기

외부 제어 인터페이스는 관리용 진입점이지 일반 프록시 진입점이 아닙니다. 대시보드가 필요하다면 우선 로컬 또는 접근이 통제된 네트워크로 제한하고 적절한 인증을 설정하세요. 공용 네트워크에 직접 노출하지 마세요. LAN 프록시를 열 때도 허용 범위와 방화벽 규칙을 별도로 설정해야 합니다. 관리 인터페이스, 구독 인증 정보, 프록시 인증은 서로 다른 대상을 보호하므로 한 가지를 설정했다고 나머지까지 자동으로 보호되는 것은 아닙니다. 배포할 때는 각 항목의 실제 수신 주소를 개별적으로 확인하세요.

라우터나 게이트웨이에 배포하면 다른 기기에도 영향을 주므로 단일 기기보다 위험 범위가 훨씬 넓습니다. 테스트 기기와 우회 복구 방법을 먼저 마련하고 네트워크 대역, DHCP, DNS, 출구 라우팅의 관계를 확인한 뒤 제어 범위를 단계적으로 넓히세요. IPv4가 정상이라고 IPv6 경로도 같다는 보장은 없으며 웹페이지 테스트 한 번으로 UDP까지 정상이라고 판단할 수도 없습니다. 제어 범위를 넓힐 때마다 직접 연결, 프록시, 내부망 서비스를 모두 확인하세요. 외부 사이트 하나만 테스트해서는 안 됩니다.

마지막으로 현재 환경에 맞는 점검 목록을 작성하세요. 코어 시작, 구독 업데이트, 직접 연결 규칙, 프록시 규칙, DNS, 네트워크 전환, 종료 후 복구를 포함해야 합니다. 수정할 때마다 주요 변수를 하나만 바꾸고 변경 전후의 로그와 설정 차이를 보관하세요. 테스트가 실패하면 확인된 정상 상태로 먼저 되돌린 다음 원인을 정리하세요. 가장 짧은 연결 절차를 다시 확인하려면 사용 가이드로 돌아가세요. 클라이언트를 바꾸려면 먼저 다운로드 센터를 확인하세요. 네트워크 문제를 모두 해결하려고 클라이언트부터 바꾸지는 마세요.