프로필과 구독의 관계
Clash 클라이언트에서 프로필은 선택해 불러올 수 있는 설정 파일을 뜻합니다. 원격 구독에서 가져올 수도 있고, 컴퓨터에 저장된 YAML 파일일 수도 있습니다. 프로필에는 설정 내용뿐 아니라 출처 주소, 업데이트 시간, 업데이트 주기 같은 클라이언트 정보가 기록되기도 합니다. 코어가 실제로 읽는 것은 클라이언트가 처리한 설정이며, 화면에 표시된 프로필 카드 자체가 아닙니다.
이 점을 이해하면 자주 혼동하는 세 가지 작업을 구분할 수 있습니다. 가져오기는 설정을 목록에 추가하는 작업이고, 업데이트는 설정 내용을 다시 받아오는 작업이며, 활성화는 설정을 코어에 전달해 실행하는 작업입니다. 가져오기에 성공했다고 활성화된 것은 아니며, 다운로드에 성공해도 코어가 새 내용을 받아들였다는 뜻은 아닙니다.
| 항목 | 저장되는 내용 | 주의할 점 |
|---|---|---|
| 구독 링크 | 원격 콘텐츠를 가져오는 주소로, 액세스 토큰이 포함되는 경우가 많음 | 민감 정보이므로 공개하지 않는 것이 좋음 |
| 로컬 설정 | 노드, 그룹, 규칙 등을 포함할 수 있는 YAML 텍스트 | 이후에는 대개 직접 관리해야 함 |
| 프록시 프로바이더 | 설정에서 참조하는 별도의 노드 리소스 | 프로필 전체 업데이트와는 다른 수준의 기능 |
| 실행 설정 | 오버라이드와 병합을 거쳐 실제로 코어에 전달되는 내용 | 원본 구독 파일과 다를 수 있음 |
특히 전체 구독과 proxy-providers를 구분해야 합니다. 전자는 포트, DNS, 그룹, 규칙을 함께 정의할 수 있습니다. 후자는 주로 노드를 제공하며, 기본 설정의 정책 그룹이 use를 통해 참조합니다. rule-providers는 규칙 세트를 제공하며 프록시 노드는 제공하지 않습니다.
구독 링크 가져오기
먼저 응답 형식을 확인하세요
같은 서비스에서 여러 구독 형식을 제공할 수 있습니다. 다른 프록시 프로그램용 노드 목록을 Clash용 전체 YAML 설정으로 바로 사용할 수 있는 것은 아닙니다. 서비스 제공자가 명시한 Clash 또는 mihomo 형식을 우선 선택하세요. VLESS, Hysteria2 등의 프로토콜이 포함되어 있다면 클라이언트에서 실제 사용하는 코어가 해당 프로토콜을 지원하는지도 확인해야 합니다. 앱 이름에 Clash가 들어가는지만 봐서는 안 됩니다.
- 클라이언트에서 ‘설정’ 또는 ‘Profiles’ 페이지를 찾아 링크 가져오기 메뉴를 이용하세요. 클라이언트마다 버튼 이름이 ‘새로 만들기’, ‘가져오기’, ‘추가’ 등으로 다를 수 있으니 현재 화면의 안내를 따르면 됩니다.
- 주소 전체를 붙여 넣고 앞뒤에 공백이나 따옴표, 메신저가 덧붙인 문장 부호가 없는지 확인하세요. ‘집에서 사용’이나 ‘출장용’처럼 용도를 알아보기 쉬운 이름을 붙입니다.
- 가져온 뒤 업데이트 시간을 확인하고 해당 프로필을 직접 선택하세요. 로그에 파싱 실패, 알 수 없는 필드, 정책 그룹 참조 오류가 나타나는지 살펴봅니다.
- 프록시 그룹을 열어 노드 목록이 있는지 확인한 다음, 해당 그룹을 거치는 것이 확실한 새 연결을 테스트하세요. 문제 원인을 혼동하지 않도록 우선 DNS와 TUN 설정은 동시에 변경하지 않는 것이 좋습니다.
가져오기에 실패하면 응답 내용을 먼저 확인하세요
오류 메시지에 YAML이 언급되는데 응답이 <html>로 시작한다면 로그인 페이지나 오류 페이지를 내려받았을 수 있습니다. HTTP 401, 403은 인증 만료나 액세스 제한과 관련된 경우가 많고, 429는 대개 요청 횟수 제한을 뜻합니다. 먼저 구독 출처를 확인하세요. 업데이트 버튼을 반복해서 누르거나 오류를 우회하려고 TLS 인증서 검증을 함부로 끄지 마세요.
로컬 설정과 최소 예제
로컬 프로필은 규칙을 고정해 두거나 오프라인에서도 설정을 보관하려는 경우, 또는 각 필드의 의미를 익히려는 경우에 적합합니다. UTF-8 인코딩으로 profile-local.yaml 파일을 만들고, 들여쓰기에는 탭 대신 공백을 사용하세요. 아래는 구조를 이해하기 위한 최소 설정입니다. 로컬 7890 포트에서 수신하며, 직접 연결 옵션 하나만 있고 원격 프록시 노드는 포함하지 않습니다.
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
proxy-groups:
- name: 수동 선택
type: select
proxies:
- DIRECT
rules:
- MATCH,수동 선택mixed-port: 7890은 HTTP와 SOCKS 프록시 접속 포트를 제공합니다. 포트 번호는 이 예제의 설정일 뿐이며 모든 클라이언트가 7890을 사용하는 것은 아닙니다.allow-lan: false는 다른 LAN 기기의 접속을 허용하지 않습니다. 처음 설정할 때는 이 값을 유지해 불필요한 네트워크 노출을 줄이세요.mode: rule은 규칙 모드를 사용합니다. 마지막의MATCH는 앞선 규칙에 일치하지 않은 연결을 처리합니다.수동 선택은 정책 그룹 이름이므로 규칙에서 참조할 때 글자를 정확히 일치시켜야 합니다. 이 예제에서는 마지막에DIRECT를 선택하므로 트래픽은 계속 직접 연결됩니다.
파일을 로컬 설정으로 가져와도 클라이언트가 수신 포트, 실행 모드 또는 DNS를 덮어쓸 수 있습니다. 문제를 확인할 때는 YAML만 보는 대신 원본 파일, 클라이언트 설정, 실행 설정을 함께 살펴보세요. 코어 필드와 호환성은 코어 설정 참고에서 확인할 수 있습니다.
시스템에 실행 가능한 mihomo가 있다면 파일이 있는 디렉터리에서 다음 구문 검사를 실행할 수 있습니다. 검사를 통과했다는 것은 해당 코어가 설정을 불러올 수 있다는 뜻일 뿐, 노드에 연결할 수 있거나 데스크톱 시스템 프록시가 켜졌다는 뜻은 아닙니다.
mihomo -t -f ./profile-local.yaml자동 업데이트 주기 설정
노드 변경이 잦지 않은 일반적인 설정이라면 프로필 자동 업데이트를 우선 24시간 간격으로 설정해 보세요. 노드를 자주 변경하는 서비스는 제공자의 안내에 따라 6시간 간격으로 바꿀 수 있습니다. 이는 설정을 시작하기 위한 기준이지, 성능을 측정한 결과가 아닙니다. 업데이트 주기를 짧게 해도 기존 노드의 지연 시간이 줄어들지는 않으며, 오히려 서버의 요청 제한에 걸릴 수 있습니다.
단위를 확인한 뒤 값을 입력하세요
- 클라이언트에서 단위를 ‘분’으로 표시한다면 24시간은
1440을 입력하고, ‘시간’ 단위라면24를 입력하세요. - mihomo HTTP 프록시 프로바이더의
interval: 86400은 86400초, 즉 24시간을 뜻합니다. 이 필드는 GUI의 프로필 업데이트 주기가 아닙니다. - 프로바이더의 상태 확인 주기인
health-check.interval은 노드 상태를 검사하는 빈도이며, 구독을 다시 다운로드하는 주기가 아닙니다. 0이 항상 비활성화를 뜻한다고 단정하지 마세요. 클라이언트마다 동작이 다를 수 있으니 자동 업데이트가 명확히 표시된 스위치를 우선 사용하세요.
컴퓨터가 절전 상태이거나 클라이언트가 종료됐거나 네트워크를 사용할 수 없으면 업데이트 작업이 예정대로 실행되지 않을 수 있습니다. 인터넷에 다시 연결한 뒤 ‘마지막 업데이트 성공’ 시간을 확인하세요. 구독 주소를 변경했다면 수동 업데이트를 한 번 실행해 결과를 확인합니다. 자동 업데이트가 켜져 있다는 이유만으로 파일이 최신이라고 판단하지 마세요.
여러 프로필 전환 시 확인 순서
대부분의 데스크톱 클라이언트는 한 번에 주요 프로필 하나만 활성화합니다. 설정 목록에 프로필이 세 개 있다고 해서 세 서비스의 노드가 모두 하나의 정책 그룹에 동시에 로드되는 것은 아닙니다. 프로필을 전환하면 새 규칙, DNS, 정책 그룹이 함께 적용될 수 있습니다. 반면 시스템 프록시나 TUN 권한은 보통 클라이언트가 관리하므로 프로필 전환에 따라 함께 바뀌지 않을 수 있습니다.
- 기존 상태 기록: 현재 프로필 이름, 실행 모드, 선택된 노드와 시스템 프록시 및 TUN 스위치 상태를 기록해 둡니다.
- 새 프로필 선택: 화면에서 해당 프로필이 활성 상태인지 확인하고, 코어 로그에 로드 실패가 없는지 살펴봅니다. 로드에 실패하면 클라이언트가 이전 설정을 계속 사용할 수 있습니다.
- 정책 그룹 확인: 클라이언트가 같은 이름의 그룹에서 이전 선택을 기억할 수 있지만, 새 설정에는 기존 노드가 없을 수도 있습니다. 이전 노드가 계속 선택되어 있다고 가정하지 마세요.
- 접속 포트 확인: 앱이
127.0.0.1:7890으로 수동 설정되어 있는데 새 실행 설정은 실제로 7897 포트를 수신한다면 양쪽 설정을 일치시켜야 합니다. - 새 연결 만들기: 테스트할 페이지를 새로고침하거나 관련 앱의 연결을 종료한 뒤 다시 연결해 연결 기록에 표시된 규칙과 출구를 확인합니다. 기존 TCP 연결은 전환 즉시 다시 만들어지지 않을 수 있습니다.
‘전환 후 브라우저는 되는데 터미널은 안 되는’ 경우 구독을 바로 바꾸지 말고 먼저 터미널의 환경 변수를 확인하세요. Linux에서 다음 명령을 실행하면 흔히 사용하는 프록시 변수를 확인할 수 있습니다. 출력에 내부 주소가 포함될 수 있으므로 로그를 공유하기 전에 민감한 정보를 직접 가리세요.
printenv http_proxy https_proxy all_proxy HTTP_PROXY HTTPS_PROXY ALL_PROXY시스템 프록시는 설정을 따르는 앱에 주로 영향을 줍니다. TUN은 가상 네트워크 인터페이스로 더 많은 연결을 처리하며 관련 서비스나 권한이 필요합니다. 프로필을 전환해도 TUN 권한이 자동으로 부여되지는 않습니다. 두 기능의 사용 범위는 TUN 모드 안내를 참고해 항목별로 확인하세요.
설정 병합 시 확인할 충돌 항목
여러 출처를 한 설정에서 사용해야 한다면 기본 설정에 proxy-providers를 연결하거나 클라이언트에서 공식 지원하는 병합 기능을 사용하세요. 완성된 YAML 파일 두 개를 단순히 이어 붙이지 마세요. 중복된 최상위 키는 파서에서 거부되거나 기존 값을 덮어쓸 수 있으며, 노드와 규칙이 자동으로 합쳐지는 것은 아닙니다.
| 충돌 항목 | 처리 방법 |
|---|---|
| 노드 및 정책 그룹 이름 | 출처별 접두어를 붙이고 모든 참조도 함께 수정 |
| 규칙 목록 | 적용 순서를 명확히 하고 기본값인 MATCH는 마지막에 배치 |
| DNS 및 수신 포트 | 기본 설정에서 통합 관리하고 두 값을 그대로 이어 붙이지 않기 |
| 프로바이더 캐시 경로 | 리소스마다 별도의 경로를 사용해 서로 덮어쓰지 않도록 설정 |
규칙은 개수보다 순서가 중요합니다
규칙은 일반적으로 위에서 아래 순서로 적용됩니다. 사용자 지정 규칙을 MATCH,DIRECT 뒤에 추가하면 기본값 규칙이 연결을 먼저 처리하므로 뒤의 규칙은 예상대로 적용되지 않습니다. 클라이언트에서 ‘앞에 추가’와 ‘뒤에 추가’를 선택할 수 있다면 편집기에 저장됐다는 메시지만 보지 말고 최종 설정에서 규칙이 들어간 위치를 확인하세요.
또한 일반적인 전체 구독은 proxy-providers 리소스로 바로 사용할 수 없는 경우가 있습니다. 프로바이더에는 코어가 지원하는 노드 리소스 형식이 필요합니다. 병합 도구가 배열을 추가하지 않고 통째로 교체할 수도 있습니다. 한 번에 출처 하나만 추가하고 로드 테스트를 통과한 뒤, 실행 설정의 노드 수와 정책 그룹 참조, 규칙의 마지막 부분을 확인하세요. 여러 설정을 한꺼번에 붙여 넣는 것보다 문제를 찾기 쉽습니다.
백업, 복구 및 자주 묻는 질문
구독 주소만 백업해서는 안 됩니다
구독 주소로 원격 콘텐츠를 다시 내려받을 수는 있지만 사용자 지정 규칙, 클라이언트 오버라이드, 정책 선택을 완전히 복구할 수는 없습니다. 처음 정상 작동했을 때와 규칙을 크게 변경하기 전에 각각 백업하고 날짜를 붙여 구분하세요. 정상 작동이 확인된 로컬 설정을 하나 보관해 두면 복구할 때 도움이 됩니다.
- 설정 파일: 로컬 YAML, 사용할 수 있는 원격 설정 스냅샷, 출처 이름과 업데이트 시간을 저장합니다.
- 사용자 지정 계층: 오버라이드 파일, 병합 스크립트, 직접 관리하는 규칙 리소스를 저장합니다. 실행 중 생성된 파일만 복사하지 마세요.
- 클라이언트 설정: 수신 포트, 시스템 프록시, TUN, 업데이트 주기를 기록하고 클라이언트에서 공식 제공하는 내보내기 기능을 우선 사용합니다.
- 개인정보 보호: 백업에는 노드 비밀번호, 구독 토큰, 제어 인터페이스 키가 포함될 수 있으므로 접근이 제한된 디렉터리에 보관하세요. 다른 기기와 동기화할 때는 보호된 저장 방식을 사용합니다.
업데이트 후 규칙이 원래대로 돌아오는 이유는 무엇인가요?
가장 흔한 원인은 원격 파일 자체를 수정한 경우입니다. 변경 사항을 클라이언트의 별도 오버라이드 계층으로 옮긴 뒤 생성된 설정에 규칙이 유지되는지 확인하세요. 임시 실행 파일을 계속 직접 편집하지 마세요. 재시작, 프로필 전환 또는 업데이트 시 파일이 다시 생성될 수 있습니다.
로컬 설정은 왜 자동 업데이트되지 않나요?
로컬에서 가져온 설정에는 파일 내용만 있고 원격 출처가 없는 경우가 많습니다. 일부 클라이언트는 원본 경로를 계속 읽는 대신 파일을 복사하므로 디스크의 원본을 수정해도 즉시 반영되지 않을 수 있습니다. 클라이언트가 파일 연결을 지원하는지 확인하세요. 지원하지 않으면 다시 가져오거나 클라이언트의 편집 기능을 이용한 뒤 설정을 다시 불러오세요.
이전 설정을 복원해도 연결되지 않으면 어떻게 하나요?
먼저 코어가 이전 프로필을 정상적으로 불러왔는지 확인한 다음 구독 만료 여부, 시스템 시간, 포트 사용 상태를 점검하세요. 설정을 복원해도 서버에서 삭제된 노드가 되살아나거나 시스템 권한이 자동으로 갖춰지지는 않습니다. ‘설정 로드 → 접속 포트 → 규칙 적용 → 노드 연결’ 순서로 확인하는 편이 여러 스위치를 동시에 바꾸는 것보다 효과적입니다. 구독 관련 문제는 구독 자주 묻는 질문에서 확인하세요.