Clash 클라이언트와 구독 설정 완벽 가이드

1. 핵심 개념: 클라이언트, 코어, 설정

요청은 어떤 과정을 거칠까

Clash 생태계는 모든 인터페이스가 똑같은 하나의 프로그램으로 이루어져 있지 않습니다. 클라이언트는 설정 가져오기, 모드 선택, 시스템 설정, 로그 확인 기능을 제공하고, 코어는 연결을 받아 규칙을 해석한 뒤 외부 연결을 처리합니다. 보통 두 요소는 설치 패키지에 함께 포함되지만 업데이트 주기는 다를 수 있습니다. 기능 지원 여부를 판단할 때는 화면에 스위치가 있는지만 보지 말고, 실제 실행 중인 코어가 해당 필드를 인식하는지도 확인해야 합니다. 클라이언트 이름만으로 지원 여부를 단정할 수는 없습니다.

요청은 앱, 연결 방식, 코어, 규칙, 아웃바운드 순서로 흐른다고 이해하면 됩니다. 앱이 로컬 프록시 포트를 직접 사용하거나 시스템 프록시 설정을 통해 요청을 전달할 수 있습니다. TUN을 켜면 가상 네트워크 인터페이스가 트래픽을 가로챌 수도 있습니다. 코어는 요청을 받은 뒤 모드와 규칙에 따라 직접 연결하거나 차단하거나 특정 정책 그룹으로 전달합니다. 이 흐름을 이해하면 웹페이지 접속 실패가 앱 연결, 도메인 조회, 원격 연결 중 어느 단계에서 발생했는지 구분하기 쉽습니다.

구독이 전체 설정을 의미하지는 않습니다

구독 URL은 원격 리소스를 가져오는 주소이지, 연결을 켜는 스위치가 아닙니다. 응답으로 전체 설정 파일이 올 수도 있고, 프록시 제공자가 사용하는 리소스 파일만 올 수도 있습니다. 전체 설정에는 보통 프록시, 정책 그룹, 규칙, DNS가 함께 포함되지만 리소스 파일은 그중 일부만 담당합니다. 노드 목록을 전체 설정처럼 가져오면 형식 오류가 나거나, 리소스만 있고 사용할 정책 그룹이 없을 수 있습니다. 가져오기 전에 제공자가 안내한 형식과 대상 클라이언트의 요구 사항을 확인하세요.

설정 파일은 계층 구조를 표현할 때 YAML을 자주 사용하며 들여쓰기에도 의미가 있습니다. 최상위 필드와 하위 필드는 임의로 바꿀 수 없고, 목록 항목은 보통 하이픈으로 시작합니다. 탭 대신 공백으로 들여쓰기하세요. 같은 이름의 필드가 반복되면 파서마다 처리 방식이 다를 수 있으므로, 나중 값이 앞선 값을 덮어쓰리라 기대하지 말고 직접 합치세요. 문법 오류가 없더라도 정책 그룹 참조, 리소스 경로, 실행 권한이 올바르다는 뜻은 아닙니다. 구문 검사는 첫 번째 확인 단계일 뿐입니다.

설정 출처와 실행 상태

클라이언트 화면에서는 원본 구독, 덮어쓰기 파일, 최종 적용 설정을 구분해야 합니다. 원격 구독은 업데이트 때 다시 다운로드될 수 있고, 덮어쓰기 기능은 로컬 포트·규칙·DNS 변경 사항을 유지하는 데 사용됩니다. 최종 설정은 클라이언트가 항목을 병합해 코어에 전달한 결과입니다. 설정이 초기화되거나 필드가 적용되지 않거나 규칙 순서가 달라졌다면 다운로드한 임시 파일을 반복해서 편집하기보다 최종 설정을 먼저 확인하세요. 클라이언트마다 배열을 병합하는 방식이 다르므로 모든 덮어쓰기가 항목을 추가한다고 가정하면 안 됩니다.

‘설정을 저장함’, ‘코어에 불러옴’, ‘대상 앱이 프록시를 사용함’은 서로 다른 상태입니다. 편집기가 저장을 완료해도 코어가 새 내용을 받아들였다는 뜻은 아닙니다. 코어가 설정을 불러왔더라도 브라우저나 다른 앱이 연결되었다는 보장은 없습니다. 신뢰할 수 있게 확인하려면 불러오기 결과와 연결 기록을 함께 살펴본 뒤 대상 앱에서 새 요청을 보내세요. 기존 연결은 이전 아웃바운드를 계속 사용할 수 있으므로 열린 탭이나 기존 세션만 관찰하면 캐시 동작을 설정 미적용으로 오해할 수 있습니다.

2. 클라이언트 선택: 플랫폼, 코어, 유지 관리 방식

운영체제와 사용 방식부터 정하세요

클라이언트는 먼저 운영체제를 기준으로 고르고, 다음으로 프로세서 아키텍처와 사용 환경을 확인하세요. 데스크톱과 스마트폰에서는 그래픽 인터페이스를 우선 선택하고, 서버와 라우터에서는 코어를 직접 실행하는 방식을 고려할 수 있습니다. 이 사이트의 다운로드 페이지에서는 지원되는 플랫폼에 Clash Plus를 우선 안내합니다. 데스크톱 설정 관리와 mihomo 기능이 필요하다면 Clash Verge Rev와 FlClash도 비교해 보세요. 추천 순서가 모든 기능의 동일성을 보장하는 것은 아니므로 구독 형식, 연결 방식, 플랫폼 권한을 각각 확인해야 합니다.

Windows에서는 시스템 설정에서 시스템 종류를 확인하고 x64와 ARM64를 구분하세요. macOS는 운영체제 이름만 보고 파일을 고르지 말고 Intel인지 Apple Silicon인지 확인해야 합니다. Android에서는 기기 아키텍처에 맞는 설치 파일을 우선 선택하고, 확실하지 않다면 다운로드 페이지의 범용 패키지 옵션을 살펴보세요. Linux는 아키텍처뿐 아니라 배포판의 패키지 형식과 데스크톱 환경도 고려해야 합니다. 설치가 된다고 해서 트레이 아이콘, 서비스 관리, 권한 안내가 똑같이 작동하는 것은 아닙니다.

이름만으로 기능 호환성을 판단하지 마세요

Clash, Clash Meta, mihomo는 서로 발전해 온 관계지만, 항상 같은 필드를 지원하는 별칭은 아닙니다. 프로토콜, 규칙 유형, DNS 옵션은 코어 구현에 따라 달라질 수 있으며 온라인 설정도 서로 다른 분기를 대상으로 할 수 있습니다. 클라이언트를 옮길 때는 현재 사용하는 핵심 기능을 먼저 기록한 뒤 대상 클라이언트에서 하나씩 확인하세요. 특히 프록시 제공자, 규칙 제공자, 스크립트 기능, 플랫폼 전용 연결 방식을 주의 깊게 살펴보고 과거 설정을 한꺼번에 옮기지 마세요.

모바일에서는 설정 형식도 확인해야 합니다. Surfboard의 설정 체계는 Clash YAML과 같지 않으므로 다운로드 페이지에 함께 소개된 프록시 앱이라는 이유만으로 같은 파일을 모두 가져올 수는 없습니다. iOS에서는 다운로드 페이지에서 Clash Plus 스토어 페이지로 이동하고 공식 사이트 clashplus.io에서 제품 안내를 확인할 수 있습니다. 앱에서 실제로 지원하는 가져오기 메뉴를 기준으로 사용하세요. 데스크톱 필드를 모바일 설정에 그대로 대응시킬 수는 없습니다.

보관된 클라이언트와 이전 비용

Clash for Windows와 ClashX Meta는 다운로드 페이지에서 지원이 종료된 보관용 옵션으로 제공됩니다. 구형 환경과의 호환성이나 과거 설정을 확인하는 용도에 적합하며, 오래된 튜토리얼의 스크린샷만을 새 설치의 기준으로 삼아서는 안 됩니다. 계속 유지 관리되는 클라이언트를 선택하더라도 설정 저장 위치, 로그 내보내기 방법, 제거 후 시스템 설정 처리 방식을 알아두세요. 특히 여러 기기에서 설정을 옮기거나 장기간 유지 관리해야 한다면 인터페이스 버튼 수보다 백업과 복구가 명확한지가 더 중요합니다.

여러 클라이언트를 설치한 뒤 동시에 실행하지 마세요. 프로그램끼리 같은 포트, 시스템 프록시, VPN 연결을 두고 충돌하면 결과를 파악하기 어렵습니다. 클라이언트를 비교할 때는 같은 설정, 네트워크, 앱을 사용해 순서대로 테스트하고 매번 이전 프로그램을 종료하세요. 정상 작동 조건을 기록한 뒤 사용할 클라이언트를 결정하면 됩니다. 설치 파일과 플랫폼별 링크는 클라이언트 다운로드에서 확인하세요. 코어 간 관계는 Clash, Clash Meta, mihomo 차이점에서 살펴볼 수 있습니다.

3. 설치와 확인: 권한, 포트, 첫 실행

설치 전에 복구할 수 있는 상태를 남기세요

설치를 시작하기 전에 실행 중인 다른 프록시 클라이언트를 종료하고 시스템의 기존 프록시 설정을 기록하세요. 회사나 학교 네트워크를 사용하거나 전용 VPN이 연결된 기기라면 업무 연결이 끊기지 않도록 먼저 관리 정책을 확인해야 합니다. 구형 클라이언트를 사용했던 기기에서는 백그라운드 프로세스와 자동 시작 항목도 확인하세요. 창을 닫아도 코어 프로세스는 종료되지 않을 수 있습니다. 첫 설치는 사용자가 관리할 수 있는 일반적인 경로를 이용하고, 복잡한 폴더 권한이나 동기화 폴더 설정을 추가하지 않는 편이 좋습니다.

Windows에서는 설치 안내에 따라 설치를 마친 뒤 첫 실행에서 TUN을 끈 상태로 유지하고 기본 화면, 설정 페이지, 로그 페이지가 정상적으로 열리는지 확인하세요. 시스템 보호 경고가 나타나면 보안 기능을 전부 끄기보다 다운로드 출처와 릴리스 안내를 확인하세요. 설치 폴더에 쓰기 권한이 있는지와 실행 데이터 폴더에 쓰기 권한이 있는지는 별개의 문제입니다. 클라이언트가 실행되지만 설정을 저장하지 못한다면 데이터 폴더 권한, 디스크 공간, 동기화 프로그램이나 보안 소프트웨어의 파일 점유 여부를 확인하세요.

macOS에서는 현재 패키지의 설치 방법에 따라 배포를 완료한 뒤 시스템 안내에 따라 필요한 권한을 부여하세요. 앱을 다른 위치로 옮기면 이전 경로를 가리키는 시작 항목이나 백그라운드 서비스가 남을 수 있으므로 자동 시작을 켜기 전에 최종 위치를 정하는 것이 좋습니다. Linux에서는 배포판에 맞는 패키지 관리 방식을 사용하세요. 의존성 오류가 발생하면 패키지 관리자의 출력을 확인해 의존성 누락, 아키텍처 불일치, 그래픽 환경 문제를 구분해야 합니다. 모든 실행 실패를 구독 내용 탓으로 돌리지 마세요.

모바일 권한과 백그라운드 제한

Android에서는 설정을 가져올 때나 이후에 VPN 연결 권한을 허용해야 할 수 있습니다. 이는 시스템이 네트워크 트래픽을 처리할 통로를 만드는 권한이며 구독 인증과는 다릅니다. 처음 권한을 허용한 뒤에도 클라이언트에서 연결을 시작해야 합니다. 화면을 잠근 뒤 연결이 끊긴다면 배터리 최적화, 백그라운드 활동, 제조사별 자동 시작 설정을 확인하되 현재 기능에 필요한 권한만 부여하세요. iOS도 시스템 안내에 따라 네트워크 설정을 허용하고 다른 VPN 앱이 연결을 동시에 점유하지 않는지 확인해야 합니다.

포트 충돌과 코어 실행

데스크톱에서 흔히 사용하는 로컬 리스너는 HTTP, SOCKS, 혼합 포트입니다. 혼합 포트는 해당 HTTP 프록시와 SOCKS 연결을 함께 받을 수 있지만 모든 프로그램이 자동으로 이 포트를 사용하는 것은 아닙니다. 예시의 7890은 선택 가능한 포트일 뿐 모든 클라이언트의 고정값이 아닙니다. 로그에 주소가 이미 사용 중이라고 표시되면 점유 프로세스를 먼저 찾고 기존 프로그램을 종료하거나 포트를 변경하세요. 앱의 프록시 주소만 바꾸고 클라이언트의 리스너 설정을 그대로 두지 마세요.

# Windows PowerShell: 로컬 리스닝 포트 확인
Get-NetTCPConnection -LocalPort 7890 -State Listen

# macOS: TCP 리스닝 프로세스 확인
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux: TCP 리스닝 및 프로세스 확인
ss -lntp

확인 명령의 결과가 비어 있다면 해당 리스너를 찾지 못했다는 뜻일 뿐, 클라이언트가 반드시 손상되었다는 의미는 아닙니다. 포트가 다르거나 코어가 아직 설정을 불러오지 않았을 수 있고, 일부 프로세스 정보는 더 높은 권한으로 실행해야 표시될 수 있습니다. 먼저 클라이언트 화면에서 실제 포트와 실행 상태를 확인한 뒤 로그와 대조하세요. 프로세스가 계속 종료된다면 재설치를 반복하기보다 설정 구문 오류, 리소스 경로, 권한 안내를 먼저 확인하세요. 재설치 후에도 기존 데이터 폴더가 남을 수 있어 문제가 그대로일 수 있습니다.

4. 구독 및 업데이트: 가져오기, 리소스 주기, 덮어쓰기

내용에 맞는 가져오기 메뉴를 선택하세요

클라이언트의 설정 또는 구독 페이지에서 추가, 가져오기와 같은 메뉴를 선택한 뒤 전체 구독 URL을 해당 입력란에 붙여 넣으세요. 복사한 링크가 메신저에서 줄바꿈되지 않았는지, 앞뒤에 공백이 붙지 않았는지, 인증 매개변수가 온전히 포함되었는지 확인하세요. 가져오기에 성공하면 해당 설정을 현재 사용 설정으로 지정해야 합니다. 목록에 새 항목이 보이는 것은 기록이 생성되었다는 뜻일 뿐입니다. 다운로드, 구문 분석, 코어 적용 상태는 상태 안내와 로그로 확인하세요.

로컬 파일을 가져오면 YAML을 클라이언트 관리 폴더에 복사하거나 원본 파일을 참조할 수 있으며, 동작은 클라이언트마다 다릅니다. 원본 다운로드 파일을 수정해도 클라이언트에 자동 반영되지 않을 수 있습니다. 반대로 일부 편집 메뉴는 현재 관리 중인 파일을 직접 수정합니다. 가져온 뒤 어느 파일을 편집하는지 확인하고 원본을 백업하세요. 제공된 파일이 인코딩된 노드 목록이나 다른 설정 형식이라면 호환되는 가져오기 메뉴나 신뢰할 수 있는 변환 방법을 사용해야 합니다. 파일 확장자만 바꿔서는 안 됩니다.

전체 설정 업데이트와 리소스 업데이트

전체 구독을 업데이트하면 원격 설정 내용이 교체되고, 프록시 제공자를 업데이트하면 보통 해당 제공자의 리소스만 새로고침됩니다. 규칙 제공자에는 별도의 다운로드 주기가 적용됩니다. 이 세 작업은 서로 다른 메뉴에서 제어될 수 있으며 하나를 업데이트했다고 나머지도 갱신되는 것은 아닙니다. 클라이언트 화면의 구독 간격은 분 단위일 수 있지만 mihomo 제공자의 interval 필드는 보통 초 단위입니다. 화면에 입력한 값을 YAML에 그대로 옮기지 말고, 하나의 필드만으로 전체 설정의 업데이트 주기를 추측하지 마세요.

# 로컬 프록시 제공자 조각: 기존 설정에 병합해야 함
# 파일 내용은 현재 코어의 프록시 제공자 형식과 일치해야 함
proxy-providers:
  local-resources:
    type: file
    path: ./providers/local.yaml

proxy-groups:
  - name: 수동 선택
    type: select
    use:
      - local-resources

위 예시는 제공자와 정책 그룹의 참조 관계를 보여 줄 뿐 리소스 파일을 자동으로 생성하지는 않습니다. 사용하기 전에 코어의 실제 작업 디렉터리에 파일을 준비하고 클라이언트가 해당 경로에 접근할 수 있는지 확인하세요. HTTP 유형 제공자에는 실제 리소스 주소, 저장 경로, 업데이트 간격도 필요합니다. 주소는 신뢰할 수 있는 출처에서 받아야 하며 관리 웹페이지를 리소스 API로 사용하면 안 됩니다. 구독 응답이 HTML, 로그인 페이지, 오류 안내라면 요청 자체가 성공했더라도 YAML 리소스로 불러올 수 없습니다.

로컬 변경 사항은 지속되는 계층에 저장하세요

사용자 지정 포트, DNS, 규칙은 가능한 한 클라이언트가 지원하는 덮어쓰기, 병합, 확장 설정 기능으로 저장하세요. 원격 파일을 직접 수정하면 다음 업데이트 때 변경 사항이 사라질 수 있고, 구독 전체를 수동으로 복사하면 원격 리소스의 유지 관리 기능을 잃게 됩니다. 덮어쓰기를 설정한 뒤에는 최종 적용 설정에서 필드 계층과 배열 순서가 예상과 일치하는지 확인하세요. 특히 규칙 목록은 기능에 따라 전체 규칙을 교체하거나 앞뒤에 삽입할 수 있어 기본 규칙 처리에 큰 차이가 생깁니다.

업데이트가 실패하면 어떤 항목이 어떤 오류로 실패했는지 먼저 기록하세요. 인증 거부는 링크 유효성과 계정 상태를 확인하고, 구문 오류는 응답 내용과 형식을 살펴보며, 연결 시간 초과는 로컬 네트워크, 도메인 조회, 다운로드 경로를 구분해야 합니다. 현재 프록시가 구독에 의존하고 구독 업데이트도 현재 프록시를 필요로 하면 시작 과정에서 의존성 순환이 발생할 수 있습니다. 신뢰할 수 있는 네트워크에서 작동이 확인된 설정을 복구한 뒤 업데이트하세요. 민감한 URL을 공개 변환 서비스나 공개 문제 해결 게시판에 붙여 넣지 마세요.

5. 프록시 모드: 연결 진입점과 아웃바운드 결정

시스템 프록시와 규칙 모드는 다릅니다

시스템 프록시, TUN, 규칙 모드는 서로 다른 계층의 기능입니다. 시스템 프록시는 해당 시스템 설정을 따르는 앱이 로컬 포트로 연결을 전달하는 방식을 정하고, TUN은 다른 방식으로 트래픽을 받아들입니다. 규칙, 전역, 직접 연결 모드는 코어가 받은 연결의 아웃바운드를 결정합니다. 따라서 전역 모드로 바꿔도 프록시를 사용하지 않는 앱의 트래픽이 자동으로 들어오지는 않습니다. 시스템 프록시를 켰다고 해서 모든 요청이 원격 아웃바운드로 전달되는 것도 아닙니다. 문제를 진단할 때는 먼저 연결이 코어에 들어왔는지 확인해야 합니다.

일상적인 사용은 보통 규칙 모드에서 시작해 도메인, 주소, 기타 조건에 따라 연결 경로를 결정합니다. 전역 모드는 특정 아웃바운드가 작동하는지 일시적으로 확인할 때 유용하지만, 해당 정책 그룹에서 대상 아웃바운드를 올바르게 선택해야 합니다. 직접 연결 모드는 원격 경로가 문제인지 확인하는 데 도움이 됩니다. 다만 앱이 코어에 연결되지 않았다면 이러한 비교는 진단에 도움이 되지 않습니다. 모드를 비교할 때는 같은 앱과 대상에서 새 연결을 사용해 네트워크 환경의 변화를 모드 차이로 오해하지 않도록 하세요.

반복 가능한 테스트 요청 만들기

시스템 프록시를 확인할 때는 먼저 클라이언트의 리스닝 주소와 포트를 살펴본 뒤 앱에 별도 프록시 설정이 있는지 확인하세요. 브라우저 확장 프로그램, 터미널 환경 변수, 개발 도구의 자체 설정이 시스템 기본 동작을 덮어쓸 수 있습니다. 데스크톱 시스템에서 프록시를 켰다고 터미널 명령이 같은 경로를 자동으로 사용하는 것은 아니므로 명시적인 매개변수로 테스트하는 편이 좋습니다. 아래 명령은 요청을 로컬 혼합 포트로 직접 보냅니다. 포트가 다르면 함께 수정하세요. 대상 사이트는 간단한 HTTPS 요청을 보내기 위한 용도입니다.

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

응답을 받았다는 것은 이번 요청이 지정한 포트를 통해 연결되었다는 뜻이지, 반드시 원격 프록시를 사용했다는 의미는 아닙니다. 최종 아웃바운드는 현재 모드와 규칙에 따라 달라지므로 클라이언트의 연결 페이지에서 확인하세요. 로컬 포트 연결부터 실패하면 리스너와 프로세스를 살펴보세요. 인증서 오류가 나타나면 시스템 시간, 인증서 환경, 대상 사이트를 확인하고 평소에 인증서 검증을 건너뛰는 방식으로 해결하지 마세요. HTTP 상태 코드도 응답 출처와 함께 해석해야 하며 모든 오류를 노드 문제로 볼 수는 없습니다.

모드 변경과 연결 수명

모드나 정책 그룹을 바꾸면 주로 이후에 만들어지는 연결에 적용되며 기존 장시간 연결은 이전 경로를 계속 사용할 수 있습니다. 브라우저 연결 풀, 메신저 세션, 다운로드 작업은 특히 이전 연결을 유지하기 쉽습니다. 정확히 확인하려면 앱에서 새 요청을 보내고, 필요한 경우 대상 연결을 닫거나 앱을 다시 시작하세요. 곧바로 전체 설정을 초기화할 필요는 없습니다. 클라이언트에서 연결을 직접 끊을 수 있다면 작업 범위를 확인해 전송 중인 중요한 작업이 중단되지 않도록 하세요.

클라이언트를 종료한 뒤 웹페이지에 접속할 수 없다면 시스템 프록시가 더는 리스닝하지 않는 로컬 포트를 가리키는 경우가 흔합니다. 시스템 네트워크 설정에서 남아 있는 프록시를 먼저 끄고 다른 프로그램이 설정을 다시 쓰는지 확인하세요. 터미널 환경 변수를 사용한다면 해당 세션의 프록시 변수도 정리해야 합니다. 직접 연결이 복구된 뒤 클라이언트를 다시 실행해 종료 과정을 살펴보세요. 규칙 모드와 전역 모드를 계속 바꿔도 코어 종료 후 로컬 포트에 접근할 수 없는 문제는 해결되지 않습니다.

6. 규칙 분기: 매칭 순서와 리소스 구성

최소한의 규칙 집합부터 시작하세요

규칙 모드는 보통 목록의 위에서 아래로 조건을 확인하고 먼저 일치한 규칙에 따라 요청을 처리합니다. 따라서 규칙 내용이 올바르더라도 위치가 잘못되면 실행되지 않을 수 있습니다. 구체적인 도메인이나 우선 처리해야 하는 조건은 더 포괄적인 조건보다 앞에 두고, 기본 처리용 MATCH는 맨 뒤에 배치하세요. 규칙을 추가하기 전에 연결 세부 정보에서 현재 매칭된 규칙을 확인한 뒤 삽입 위치를 정하세요. 기존 순서를 모른 채 끝에 추가하면 파일만 길어지고 실제 동작은 달라지지 않을 수 있습니다.

도메인 규칙과 주소 규칙은 서로 다른 문제를 처리합니다. DOMAIN은 지정한 도메인과 일치하고 DOMAIN-SUFFIX는 해당 도메인과 하위 도메인을 포함하며 IP-CIDR은 IP 주소 대역을 기준으로 판단합니다. 앱이 IP에 직접 연결하거나 도메인 정보가 코어에 전달되지 않으면 예상한 도메인 규칙과 일치하지 않을 수 있습니다. 이때는 같은 도메인 규칙을 반복해서 추가하기보다 연결 기록에 표시된 대상 정보를 확인하세요. 규칙이 필요로 하는 매칭 정보가 실제로 전달되어야 합니다.

# 최소 규칙 예시: 원격 프록시 리소스는 포함하지 않음
mode: rule
rules:
  - DOMAIN,example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,DIRECT

이 설정은 규칙 순서와 구문을 이해하기 위한 예시이며, 매칭되지 않은 요청은 모두 직접 연결됩니다. 완전한 프록시 설정은 아닙니다. 특정 요청을 사용자 지정 정책 그룹으로 보내려면 먼저 그룹을 정의한 뒤 규칙의 대상으로 정확히 같은 그룹 이름을 지정하세요. 이름의 공백과 대소문자는 실제 설정 내용에 맞춰야 합니다. no-resolve는 해당 주소 규칙을 위해 도메인 조회를 적극적으로 실행하지 말라는 뜻입니다. 요청에서 DNS 조회가 절대 발생하지 않는다거나 모든 주소 매칭이 차단된다는 의미는 아닙니다.

정책 그룹과 규칙 집합은 따로 관리하세요

정책 그룹은 아웃바운드를 선택하고 규칙은 정책 그룹을 선택합니다. 수동 선택 그룹은 현재 출구를 직접 제어해야 할 때 적합하며, 자동 테스트나 장애 조치 그룹은 테스트 대상, 간격, 판정 로직에 따라 동작합니다. 테스트 대상에 접근할 수 있다고 해서 실제 서비스도 정상 작동한다는 보장은 없습니다. 앱마다 프로토콜, 지역, 인증, 원격 제한의 영향을 받을 수 있습니다. 한 가지 테스트 결과만으로 실제 서비스 검증을 대신하지 말고, 겉으로 빨리 바뀌는 것처럼 보이도록 테스트 간격을 지나치게 짧게 설정하지 마세요.

규칙이 많아지면 규칙 제공자를 사용해 나누어 관리할 수 있지만 리소스의 동작 유형을 맞춰야 합니다. 도메인 목록, 주소 목록, 완전한 규칙 조건을 포함한 리소스 파일은 형식이 서로 다르므로 다운로드 주소만 바꿔서는 안 됩니다. 제공자를 정의한 뒤에는 해당 규칙에서 참조해야 합니다. 그래야 파일 다운로드가 실제 분기에 반영됩니다. 경로, 이름, 동작 유형을 함께 확인하세요. 리소스 파싱에 실패했을 때 기존 리소스를 유지할지 여부는 클라이언트와 코어 상태에 따라 다르므로 로그에서 실제 결과를 확인해야 합니다.

매칭 결과를 기준으로 분기 문제를 찾으세요

문제를 진단할 때는 먼저 대상 도메인, 실제 대상 주소, 매칭된 규칙, 최종 정책 그룹을 기록한 뒤 수정 사항을 검토하세요. 웹페이지 하나도 기본 도메인, 정적 리소스, 인증 API 등 여러 도메인에 요청할 수 있으므로 기본 도메인만 고쳐서는 페이지 전체가 정상적으로 로드되지 않을 수 있습니다. 서비스 전체를 하나의 도메인 접미사 규칙으로 묶기보다 요청별로 실패 대상을 확인하세요. LAN 기기에서는 실제 대상 서브넷도 확인해야 합니다. 예시에 나온 사설 주소 대역이 모든 가정·회사·가상 네트워크를 포함하는 것은 아닙니다.

규칙을 업데이트할 때는 공급망 범위도 고려해야 합니다. 출처를 확인할 수 있는 규칙 리소스를 선택하고 어떤 범주를 다루는지, 업데이트가 트래픽 경로를 바꿀 수 있는지 알아두세요. 대규모 규칙 집합을 여러 개 합치면 중복이나 겹치는 조건 때문에 유지 관리가 어려워질 수 있습니다. 규칙 수가 늘어난다고 분기가 정확해지는 것은 아닙니다. 먼저 명확하게 필요한 규칙만 유지하고 연결 기록을 바탕으로 예외를 추가하세요. 규칙을 추가할 때마다 적용 목적을 기록하고 업데이트 후 주요 앱이 예상대로 작동하는지 확인해야 합니다.

7. TUN 및 DNS: 네트워크 트래픽과 이름 조회 범위

TUN이 정말 필요한지 먼저 확인하세요

TUN은 가상 네트워크 인터페이스로 트래픽을 받아 시스템 프록시 설정을 따르지 않는 앱에 사용할 수 있지만, 네트워크 문제를 모두 해결하는 만능 스위치는 아닙니다. 활성화하면 라우팅, 권한, DNS, 다른 네트워크 소프트웨어와의 연동이 필요해 단순한 로컬 포트 프록시보다 복잡해집니다. 먼저 일반 프록시 경로를 정상 작동시킨 뒤 TUN을 켜고 연결 범위를 비교하세요. 모바일의 시스템 VPN 인터페이스와 데스크톱 가상 네트워크 어댑터는 권한과 구현 방식이 다르므로 같은 화면 조작을 그대로 적용할 수 없습니다.

데스크톱 클라이언트는 인터페이스 생성과 경로 변경 권한을 얻기 위해 서비스 구성 요소를 사용할 수 있습니다. 활성화하기 전에 스위치 색상만 보지 말고 서비스 상태와 시스템 안내를 확인하세요. 회사 VPN, 컨테이너 네트워크, 다른 터널이 동시에 실행되면 라우팅 우선순위와 DNS 처리에서 충돌이 발생할 수 있습니다. 테스트할 때는 트래픽을 가로채는 방식을 하나만 유지하고 기존 경로 동작을 기록하세요. 원격 기기에서는 경로 변경 후 관리 연결이 끊기지 않도록 복구 경로를 준비해야 합니다.

# mihomo TUN 예시: 병합 전에 클라이언트 서비스와 플랫폼 지원 여부 확인
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

이 설정 조각은 모든 플랫폼에서 쓸 수 있는 범용 스위치가 아닙니다. auto-route는 관련 라우팅을 자동으로 설정하고 auto-detect-interface는 아웃바운드 인터페이스를 찾는 데 도움을 주지만, 실제 결과는 시스템과 네트워크 환경에 따라 달라집니다. 클라이언트 화면에서 이미 해당 필드를 관리한다면 덮어쓰기 설정이 서로 충돌하지 않도록 지속적으로 사용할 설정 경로를 하나만 선택하세요. Wi-Fi, 유선 네트워크, 핫스팟을 바꾼 뒤 연결에 문제가 생기면 구독을 바꾸기보다 인터페이스 감지 결과와 경로가 갱신되었는지 확인하세요.

DNS와 Fake-IP 설정의 관계

DNS는 도메인을 IP 주소로 변환하며 도메인 기반 분기와 아웃바운드 선택에 필요한 정보를 제공합니다. 시스템 DNS, 브라우저의 암호화 DNS, 클라이언트 내장 DNS, 원격 조회가 동시에 사용될 수 있으므로 실제 조회가 어떤 경로를 이용하는지 먼저 파악해야 합니다. TUN에서 일반 DNS 포트를 가로채더라도 앱 내부의 모든 암호화 DNS까지 가로채는 것은 아닙니다. 특정 검사 페이지에 표시된 리졸버 하나만으로 모든 요청이 유출되었다거나 DNS가 완전히 정상이라고 단정할 근거는 부족합니다.

Fake-IP 모드는 도메인에 가상 주소를 할당하고, 코어는 매핑 정보를 이용해 원래 도메인을 확인한 뒤 연결을 처리합니다. 이 주소는 웹사이트의 실제 서버 주소가 아니므로 가상 주소가 보인다고 해서 DNS 오류라고 볼 수는 없습니다. 일부 LAN 기기 탐색, 기기 인증, 특수 프로토콜은 이 방식과 호환되지 않을 수 있습니다. 전체 모드를 바로 포기하기보다 실제 호환 문제가 있는 도메인만 필터 예외로 설정하세요. 예외 범위가 넓을수록 동작을 설명하기 어려워지므로 대상 하나부터 확인하는 것이 좋습니다.

DNS 업스트림, 프록시 서버 도메인 조회, 직접 연결 요청의 DNS 조회에는 시작 단계의 의존 관계가 있습니다. 업스트림 조회에 프록시가 필요한데 프록시 서버 도메인도 같은 업스트림에 의존하면 순환이 생길 수 있습니다. 현재 코어에서 지원하는 필드에 따라 프록시 연결에 필요한 조회와 일반 트래픽용 조회를 구분해 설정하세요. 출처가 불분명한 업스트림 목록을 여러 개 복사해 한꺼번에 추가하지 마세요. 서버 수가 많다고 결과가 더 일관적인 것은 아니며 지연과 문제 해결 경로만 늘어날 수 있습니다.

트래픽 처리 범위와 종료 후 복원을 확인하세요

TUN을 켠 뒤에는 이전에 코어로 들어오지 않던 앱에서 연결 기록이 나타나는지 먼저 확인하고 규칙과 DNS 동작을 살펴보세요. LAN 연결에 문제가 생기면 서브넷 경로, 주소 충돌, 도메인 예외를 확인하세요. 네트워크를 바꾼 뒤에만 문제가 발생한다면 아웃바운드 인터페이스와 DNS 캐시를 살펴보세요. TUN을 끈 뒤에는 가상 인터페이스, 자동 경로, 시스템 DNS가 복구되었는지 확인해야 합니다. 복구가 끝나기 전에 규칙을 계속 추가하면 트래픽 처리 문제를 규칙 분기 문제로 오진할 수 있습니다.

8. 일상적인 유지 관리: 업데이트, 백업, 단계별 문제 해결

업데이트 대상을 구분하세요

일상적인 유지 관리에서는 클라이언트, 코어, 전체 구독, 프록시 제공자, 규칙 리소스를 구분해야 합니다. 클라이언트 업데이트는 주로 인터페이스, 통합 기능, 플랫폼 호환성을 바꾸고, 코어 업데이트는 프로토콜과 네트워크 동작에 영향을 주며, 리소스 업데이트는 설정 내용을 바꿉니다. 한 업데이트 메뉴가 완료되었다고 모든 대상이 같은 상태인 것은 아닙니다. 한 번에 유지 관리할 때는 먼저 리소스를 업데이트하고 검증한 다음 프로그램 업데이트를 진행하세요. 여러 요소가 동시에 바뀌면 어느 계층에서 호환 문제가 생겼는지 판단하기 어렵습니다.

프로그램을 업데이트하기 전에 현재 설정, 덮어쓰기 내용, 주요 항목을 저장하고 현재 연결 방식과 포트를 기록하세요. 복구에 필요한 정보는 백업하되 공개 저장소나 채팅방에 올리지 마세요. 클라이언트의 내보내기 기능에 시스템 서비스 상태, 외부 파일, 환경 변수가 포함되지 않을 수 있으므로 복원 전에 백업 범위를 확인해야 합니다. 파일 기반 제공자를 사용한다면 상대 경로에 해당하는 파일도 백업하세요. 기본 설정만 저장하고 리소스 디렉터리를 빠뜨리면 이전 후 구문은 정상이지만 리소스를 찾지 못할 수 있습니다.

문제가 발생한 위치를 기준으로 범위를 좁히세요

웹페이지가 열리지 않는다면 먼저 클라이언트를 종료하고 시스템 설정을 복구한 뒤 기본 네트워크를 확인하세요. 기본 네트워크도 작동하지 않는다면 Wi-Fi, 게이트웨이, 인증 페이지, 통신사 네트워크 문제부터 해결해야 합니다. 기본 네트워크가 정상이면 로컬 포트가 리스닝하는지, 앱 연결이 코어에 들어오는지, 규칙이 매칭되는지, 아웃바운드가 성공하는지 순서대로 확인하세요. 이 순서를 따르면 연결이 들어오지 않은 문제와 연결 후 발생한 문제를 구분할 수 있어 불필요하게 모든 설정을 바꾸지 않아도 됩니다.

구독 업데이트 실패와 실제 서비스 연결 실패는 서로 다른 문제일 수 있습니다. 구독 API의 인증이 만료되어도 기존 설정으로 연결할 수 있고, 반대로 실제 아웃바운드가 작동하지 않아도 구독은 다운로드될 수 있습니다. 기록할 때는 실패한 대상, 수행한 동작, 오류 유형을 분명히 적으세요. 로그의 시간 초과, 연결 거부, 이름 조회 실패, 인증 실패는 각각 의미가 다르며 모두 네트워크가 느린 것으로 볼 수 없습니다. 로그가 너무 길다면 재현 가능한 동작 하나만 실행해 범위를 좁힌 뒤 해당 시간대의 정보를 추출하세요.

속도, 지연 시간, 앱 사용 경험

연결 테스트의 지연 시간은 특정 대상과 테스트 방식에서 측정한 한 번의 결과일 뿐 실제 다운로드 속도, 안정성, 모든 사이트의 체감 성능을 나타내지는 않습니다. 속도가 느린 문제를 확인할 때는 네트워크와 테스트 대상을 고정하고 직접 연결, 여러 아웃바운드, 대상 앱의 실제 전송을 각각 비교하세요. 무선 신호, 동시 다운로드, 원격 제한, 경로 혼잡이 병목일 수 있습니다. 속도 측정을 반복하면 리소스가 소모될 수 있으므로 실제 서비스가 정상적으로 작동하는지 살펴보는 편이 단일 테스트 수치에 집착하는 것보다 유용합니다.

특정 앱 하나만 문제가 있다면 해당 앱의 프록시 설정, 도메인 조회, 연결 캐시를 먼저 확인하세요. 모든 앱에서 동시에 문제가 생긴다면 코어 상태, 연결 통로, 상위 네트워크를 살펴보세요. 규칙 모드에서만 문제가 있고 전역 모드에서는 정상이라면 매칭 규칙, 정책 그룹, 관련 DNS 경로를 확인해야 합니다. 비교할 때마다 다른 조건은 그대로 유지하고 복구 작업을 기록하세요. ‘재시작하니 해결됨’은 일시적인 복구일 수 있으므로 계속 원인을 찾으려면 재시작 전 오류 정보도 남겨야 합니다.

복구 절차와 일상적인 기록

정상 작동이 확인된 기준 설정을 보관하고 로컬 변경의 목적, 위치, 되돌리는 방법을 기록하세요. 문제가 생기면 필요한 로그를 먼저 내보낸 뒤 가장 최근의 변경을 되돌리세요. 데이터 폴더 전체를 바로 삭제하지 마세요. 클라이언트가 정상 종료되는지, 시스템 프록시를 끌 수 있는지, TUN 경로가 복원되는지 확인한 다음 기준 설정을 복구하세요. 새 설정에서만 문제가 발생한다면 전체 구독 업데이트를 중단한 채 예전 설정에 의존하기보다 변경 사항을 하나씩 병합해 문제를 일으키는 필드를 찾으세요.

9. 고급 설정: 설정 계층화와 코어 운영

연결을 넘어 결과를 설명할 수 있도록

고급 설정은 매개변수를 더 많이 추가하는 것부터 시작할 필요가 없습니다. 먼저 하나의 연결이 어떻게 처리되는지 설명할 수 있어야 합니다. 익숙한 앱 하나를 선택해 연결 방식, 접근하는 도메인, 매칭 규칙, 선택된 정책 그룹, 예상한 DNS 경로 사용 여부를 기록하세요. 이 과정을 반복해서 확인할 수 있게 된 다음 규칙 제공자, 복잡한 정책 그룹, 별도 코어를 도입하세요. 기능이 늘면 의존성도 늘어납니다. 관찰할 방법이 없으면 기능을 더할수록 오류가 깊이 숨을 수 있습니다.

설정은 리소스 출처, 공통 정책, 기기별 설정으로 계층화할 수 있습니다. 원격 리소스는 계속 업데이트해야 하는 내용을 관리하고, 공통 정책은 여러 기기에서 동일하게 적용할 분기 요구 사항을 표현하며, 로컬 계층은 포트, 경로, 인터페이스, 권한을 처리합니다. 이렇게 나누면 기기를 옮길 때 실행 파일 전체를 복사하지 않아도 되고 구독 업데이트가 로컬 설정을 덮어쓸 위험도 줄일 수 있습니다. 실제 구현은 클라이언트의 병합 기능에 따라야 합니다. 일반적인 계층화 방법이 모든 클라이언트에서 동일한 덮어쓰기 구문을 지원한다는 뜻은 아닙니다.

코어를 직접 실행하기 전에 준비할 사항

서버나 라우터에서 mihomo를 직접 실행할 수 있지만 설정 디렉터리, 프로세스, 로그, 권한, 시작 순서를 직접 관리해야 합니다. 그래픽 클라이언트가 대신 처리하던 기능은 자동으로 제공되지 않습니다. 특히 시스템 프록시, 서비스 유지, 리소스 다운로드 상태 표시가 그렇습니다. 먼저 포그라운드에서 최소 설정을 검증한 뒤 시스템 서비스 관리에 연결하세요. 시작에 실패하면 표준 출력과 오류 출력을 보존해야 합니다. 백그라운드에서 조용히 종료되면 포트에 연결할 수 없다는 사실만 보일 수 있습니다.

# 현재 코어에서 지원하는 매개변수 확인
mihomo -h

# 현재 디렉터리에서 설정을 확인한 뒤 통과하면 포그라운드로 실행
mihomo -t -d . -f config.yaml
mihomo -d . -f config.yaml

이 명령은 실행 파일이 시스템 검색 경로에 있고 현재 디렉터리에 설정과 관련 리소스가 있다고 가정합니다. -d로 지정한 작업 디렉터리는 상대 경로 해석에 영향을 줍니다. 서비스 실행 사용자와 터미널에서 로그인한 사용자가 다르면 파일을 읽지 못할 수도 있습니다. 설정 검사는 일부 문법과 참조 오류를 찾아낼 수 있지만 원격 리소스 접근, 라우팅 권한, 실제 서비스 연결까지 보장하지는 않습니다. 서비스를 등록하기 전에 요청을 끝까지 검증하고 중지와 복구 절차를 명확히 정하세요.

LAN, 제어 인터페이스, 라우터 배포

다른 기기에서 이 기기의 프록시를 사용하게 하려면 리스닝 주소, LAN 연결 허용 설정, 방화벽 범위를 함께 고려해야 합니다. 포트만 열었다고 설정이 끝나는 것은 아니며 프록시 포트를 공용 인터넷에 직접 노출해서도 안 됩니다. 신뢰하는 네트워크 범위로 제한하고 필요한 경우 인증을 설정한 뒤 클라이언트에서 실제로 지원하는 방식인지 확인하세요. 외부 제어 인터페이스는 별도로 보호해 설정 관리 기능을 일반 프록시 진입점과 혼동하지 않도록 해야 합니다. 제어 인터페이스에서 접근할 수 있는 기능은 코어 안내를 확인하세요.

라우터 배포에서는 메인 라우터와 서브 라우터 중 어떤 역할을 맡을지, 클라이언트의 게이트웨이, DNS 할당, 응답 경로도 고려해야 합니다. 서브 라우터에서 코어를 실행한다고 LAN 기기의 트래픽이 자동으로 이쪽에 전달되는 것은 아닙니다. 기기가 게이트웨이와 DNS를 어디서 받는지 확인하고 투명 프록시 경로를 검증한 뒤 규칙 분기를 추가하세요. 홈 네트워크에 DHCP 서버가 여러 개 있다면 먼저 주소 할당 충돌을 해결해야 합니다. 배포 방식은 OpenWrt 서브 라우터에서 mihomo 실행하기를 참고하세요. 데스크톱 설정을 라우터의 완성된 설정으로 그대로 사용하면 안 됩니다.

지속적인 유지 관리의 확인 기준

자동 업데이트는 설정 검사, 정상 적용, 실패 시 복구까지 연결되어야 합니다. 정해진 시간마다 다운로드한 뒤 곧바로 덮어쓰는 방식으로는 충분하지 않습니다. 리소스 다운로드가 실패하면 정상 작동이 확인된 파일을 보존하고, 설정 검사에 실패하면 배포를 중단해야 합니다. 재적용 후에는 주요 요청을 검증하세요. 규칙 변경 내역을 기록하되 자격 증명이 포함된 리소스는 공개 저장소에 올리지 마세요. 버전 관리가 필요하다면 민감 정보를 제거한 규칙과 덮어쓰기 로직만 기록하고, 민감한 입력값은 보호된 로컬 설정에서 제공하세요.