Clash 설정 파일 Profile이란? 구독 설정·로컬 설정·여러 Profile 전환

Profile: 불러와 사용할 수 있는 설정

Clash 클라이언트에서 Profile은 선택하거나 업데이트하고 편집할 수 있는 설정 항목을 뜻합니다. 설정 내용뿐 아니라 이름, 출처 URL, 업데이트 주기 같은 관리 정보가 함께 저장될 수도 있습니다. 설정은 보통 YAML 형식이며, 수신 포트, 노드, 프록시 그룹, 라우팅 규칙, DNS 등의 동작을 결정합니다. 이름과 업데이트 주기는 YAML에 기록되지 않고 클라이언트 자체 데이터베이스에 저장될 수 있습니다.

따라서 Profile은 노드 하나나 구독 계정과 같은 개념이 아닙니다. Profile 하나에 수십 개의 노드와 여러 프록시 그룹이 들어갈 수 있고, 구독 링크는 요청할 때마다 다른 내용을 반환할 수도 있습니다. 클라이언트는 출처에 연결된 설정 항목을 저장하고, 코어는 불러오거나 병합 또는 덮어쓰기 처리된 설정을 읽어 실행합니다.

먼저 세 가지 개념을 구분하세요

설정 출처: 원격 구독 URL, 로컬 파일 또는 클라이언트에서 제공하는 편집 기능입니다.
설정 내용: YAML의 proxies, proxy-groups, rules 등의 필드입니다.
실행 상태: 현재 선택한 프록시 그룹, 프록시 모드, 연결 상태와 시스템 프록시 설정입니다.

Profile을 전환하면 현재 불러온 설정이 바뀌지만, 실행 상태가 모두 기본값으로 돌아가는 것은 아닙니다. 일부 Clash 클라이언트는 프록시 그룹 선택을 기억하고, 일부는 덮어쓰기 기능으로 포트나 TUN 설정을 유지합니다. 실제 적용 상태를 확인하려면 설정 목록에서 선택된 항목만 볼 것이 아니라 현재 Profile 이름과 실행 중인 설정을 함께 확인하세요.

구독 설정과 로컬 설정의 차이

구독 설정은 원격 URL에서 가져오므로 노드, 프록시 그룹, 규칙이 변경되면 업데이트할 수 있습니다. 로컬 설정은 기기의 파일에서 불러오며 사용자가 직접 관리합니다. 둘 다 완성된 YAML 파일일 수 있습니다. 차이는 파일 확장자가 아니라 출처와 관리 방식에 있습니다.

항목	구독 설정	로컬 설정
가져오기 방법	원격 설정 URL 붙여넣기	YAML 파일을 가져오거나 드래그 앤 드롭
업데이트 방법	원격 설정을 수동 또는 예약 업데이트	수정 후 다시 불러오거나 파일 재가져오기
적합한 설정	출처에 따라 바뀌는 노드와 규칙	고정 규칙, 테스트 설정, 직접 관리하는 구성
주요 위험	출처 만료, 응답 오류, 업데이트로 수정 내용이 덮어써질 수 있음	문법 오류, 필드 호환성 문제, 만료된 노드 정보

구독 링크가 완성된 설정을 반환하지 않을 수도 있습니다

일부 링크는 완성된 Clash YAML을 반환하고, 일부는 노드 목록만 제공하며, 또 다른 형식의 구독을 반환하는 경우도 있습니다. 노드 목록만 있다면 완성된 Profile로 바로 사용할 수 있다고 보장할 수 없습니다. 가져오기 전에 출처에서 제공하는 형식을 확인하세요. 링크에 “clash”라는 단어가 있다고 해서 호환된다고 판단해서는 안 됩니다.

또한 proxy-providers는 설정 내부에서 정의하는 노드 공급자이며, 클라이언트 목록의 구독 Profile과는 다릅니다. 로컬 Profile에서 원격 provider를 참조할 수도 있고, 원격 Profile에 내장 노드와 provider가 함께 포함될 수도 있습니다. 이 경우 ‘설정 전체 업데이트’와 ‘provider 리소스 업데이트’는 별개의 작업입니다.

YAML 필드와 최소 검증 설정

먼저 설정 구조를 이해한 뒤 세부 값을 조정하세요. 지원하는 필드는 코어 버전에 따라 다를 수 있습니다. Clash Meta는 현재 mihomo라는 이름을 사용하며, 특정 mihomo 확장 필드가 과거의 모든 Clash 코어에서 지원된다고 가정해서는 안 됩니다. 다음 예시는 YAML을 불러오고 로컬 포트가 열리는지 확인하기 위한 것으로, 모든 트래픽을 직접 연결하며 프록시 노드는 포함하지 않습니다.

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

proxy-groups:
  - name: Route
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,Route

mixed-port: 7890: 하나의 포트에서 HTTP와 SOCKS 프록시 연결을 제공합니다. 7890은 이 예시에서 지정한 값이며, 모든 클라이언트의 기본 포트는 아닙니다.
allow-lan: false: 로컬 네트워크 기기의 접근을 허용하지 않습니다. 프록시를 공유해야 한다면 수신 주소와 방화벽을 별도로 확인하세요.
mode: rule: 규칙에 따라 연결을 처리합니다. 클라이언트 화면에서 선택한 모드가 이 값을 덮어쓸 수 있습니다.
proxy-groups: Route라는 선택 그룹을 정의하며, 이 예시에는 DIRECT 하나만 포함됩니다.
MATCH,Route: 마지막 대체 규칙으로, 앞선 규칙과 일치하지 않은 연결을 Route로 보냅니다.

코어로 문법 확인하기

예시를 profile-test.yaml로 저장하세요. mihomo 명령줄 코어가 설치되어 있다면 파일이 있는 디렉터리에서 다음 명령을 실행합니다:

mihomo -v
mihomo -t -f ./profile-test.yaml

첫 번째 명령은 실제 코어 버전을 표시하고, 두 번째 명령은 설정을 테스트합니다. Windows에서는 .\mihomo.exe -t -f .\profile-test.yaml을 사용할 수 있습니다. 실행 파일 이름은 설치된 파일을 기준으로 하세요. 테스트 통과는 코어가 설정을 받아들였다는 뜻일 뿐, 원격 노드에 연결되거나 시스템 트래픽이 프록시를 통과한다는 뜻은 아닙니다.

YAML 들여쓰기에는 Tab이 아닌 공백을 사용하세요. 프록시 그룹에서 참조하는 이름은 노드 또는 다른 프록시 그룹의 이름과 일치해야 합니다. DOMAIN-SUFFIX,example.com,Route 규칙을 사용한다면 Route가 정의되어 있어야 합니다. 테스트에서 오류 행이 표시되면 해당 행 주변의 들여쓰기, 콜론, 목록 기호부터 확인한 뒤 필드 호환성을 점검하세요.

가져오기, 이름 지정, 업데이트 주기

구독 설정 가져오기 순서

Clash 클라이언트의 설정 관리 화면에서 원격 가져오기 또는 구독 추가를 선택합니다. 메뉴 이름은 ‘설정’, ‘Profiles’, ‘구독’ 등으로 표시될 수 있으니 사용하는 클라이언트에서 확인하세요.
출처에서 제공한 전체 URL을 붙여넣으세요. 쿼리 매개변수는 유지하고 토큰을 직접 삭제하지 마세요. 반환되는 형식이 현재 코어에서 지원되는지도 확인합니다.
가져오기가 끝나면 노드, 프록시 그룹, 규칙이 있는지 확인한 다음 해당 Profile을 활성화하세요.
로그에서 설정을 불러온 결과를 확인하세요. 화면에 ‘다운로드 성공’이라고 표시되더라도 이후 설정 로드 과정에서 오류가 발생하지 않았는지 살펴봐야 합니다.

출처와 용도를 이름에 표시하세요

출처A-일상-원격, 출처B-예비-원격, 로컬-규칙테스트-20260729처럼 이름을 지정하는 것이 좋습니다. 출처는 관리 주체를 구분하고, 용도는 전환 목적을 파악하는 데 도움이 되며, 날짜는 테스트 스냅샷을 식별할 때 유용합니다. 구독 토큰이나 비밀번호를 이름에 넣지 말고, ‘설정1’, ‘설정2’처럼 모호한 이름도 피하세요.

구독 Profile은 이름을 고정하고 최근 업데이트 시각은 클라이언트에 기록하도록 할 수 있습니다. 로컬 테스트 설정에는 날짜를 덧붙이는 편이 좋습니다. 테스트가 끝나면 안정 버전을 로컬-일상-안정으로 저장해 두세요. 날짜만 다른 복사본이 많아져 현재 사용할 설정을 헷갈리는 일을 줄일 수 있습니다.

업데이트 주기의 단위를 확인하세요

일반적인 구독은 우선 24시간마다 한 번 업데이트하도록 설정할 수 있습니다. 이는 관리상 권장 사항이지 프로토콜 요구 사항은 아닙니다. 클라이언트에서 단위를 분으로 표시한다면 24시간은 1440, 초로 표시한다면 86400입니다. 클라이언트마다 단위가 다를 수 있으니 같은 숫자를 그대로 복사하지 마세요. 연결 문제를 해결하려고 업데이트 주기를 1분으로 줄이는 것도 피해야 합니다.

설정에서 proxy-providers 또는 rule-providers가 interval을 사용하는 경우, 단위는 보통 초입니다. 사용 중인 코어의 문서에서 정확한 단위를 확인하세요. 클라이언트의 Profile 업데이트 주기와 provider의 interval은 서로 다른 리소스를 관리하므로 하나를 다른 하나 대신 사용할 수 없습니다.

여러 Profile 전환과 연결 확인

일반적인 Clash 클라이언트는 보통 한 번에 주 Profile 하나를 활성화합니다. 설정 목록에 Profile이 10개 있어도 10개의 규칙이 동시에 적용되는 것은 아닙니다. 일부 클라이언트는 설정 병합, 덮어쓰기, 스크립트 처리를 지원하지만, 이는 명시적으로 설정해야 하는 기능입니다. 구독을 여러 개 선택하면 어떻게 실행될지 추측해서는 안 됩니다.

전환 전에 네 가지 상태를 기록하세요

주 설정: 현재 Profile 이름과 로컬 덮어쓰기 설정의 유무입니다.
프록시 모드: 규칙, 전역, 직접 연결 중 현재 모드입니다. 모드 변경을 설정 문제로 착각하지 않도록 확인하세요.
수신 포트: 현재 혼합 포트가 7890인지, 외부 앱에서도 같은 포트를 사용하는지 확인하세요.
트래픽 처리 방식: 시스템 프록시와 TUN의 활성화 여부, 필요한 시스템 권한을 확인하세요.

전환할 Profile을 클릭하고 클라이언트가 설정을 불러올 때까지 기다리세요. 로드 중에 여러 설정을 연달아 선택하지 마세요.
프록시 그룹을 열어 선택 항목이 존재하고 용도에 맞는지 확인하세요. 이전 노드 이름이 사라졌다면 사용 가능한 노드를 다시 선택합니다.
새 요청을 보내고 연결 목록에서 일치한 규칙과 최종 정책을 확인하세요. 지연 시간 테스트 결과만으로 판단하지 마세요.
결과가 예상과 다르면 마지막으로 정상 작동한 설정으로 돌아간 뒤 차이를 하나씩 비교하세요.

설정을 전환한 뒤에도 기존 장기 연결은 이전 연결 경로를 계속 사용할 수 있습니다. 브라우저, 다운로드 도구, 메시지 앱이 기존 연결을 재사용하기도 합니다. 확인할 때는 새 요청을 만들고, 필요하다면 대상 앱의 기존 연결을 종료하세요. 일부 클라이언트는 연결 종료 기능을 제공하지만, 실행 중인 전송이 끊길 수 있으므로 중요한 다운로드나 세션이 없는지 먼저 확인해야 합니다.

지정한 포트로 프록시 연결 확인하기

현재 혼합 포트가 실제로 7890이라면 다음 명령으로 시스템 프록시 설정에 의존하지 않고 로컬 HTTP 프록시 포트를 통해 curl 요청을 보낼 수 있습니다:

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

이 명령은 해당 포트를 통해 요청을 보낼 수 있는지 확인할 뿐, 원격 프록시 노드를 사용했다는 것을 단독으로 증명하지는 않습니다. 연결 기록에서 최종 정책도 확인하세요. 규칙에 DIRECT가 적용되면 요청은 직접 연결됩니다. 실제 포트가 7897이라면 명령의 포트 번호도 7897로 바꿔야 합니다.

TUN 모드는 시스템 수준에서 트래픽을 처리하는 기능이며 Profile과 같은 뜻이 아닙니다. 새 설정으로 바꾼 뒤 TUN이 계속 켜져 있어도 DNS, 라우팅, 트래픽 분기 결과가 달라질 수 있습니다. 먼저 TUN을 끈 상태에서 지정한 프록시 포트로 연결되는지 확인한 다음 TUN 처리를 점검하면 설정 문제와 시스템 권한 문제를 구분하기 쉽습니다.

업데이트로 덮어쓰기 방지와 로컬 수정 관리

원격 구독에서 내려받은 YAML을 직접 수정하면 다음 업데이트에서 변경 사항이 덮어써질 수 있습니다. 포트, 규칙, DNS를 장기간 관리해야 한다면 Clash 클라이언트에서 공식적으로 제공하는 덮어쓰기, 병합, 확장 기능을 우선 사용하세요. 이러한 기능이 없다면 로컬 설정으로 복사해 관리할 수 있지만, 이후 노드를 직접 동기화해야 합니다.

설정 내용별 관리 주체 정하기

내용	권장 관리 위치	업데이트 후 확인 사항
노드 주소와 인증 정보	신뢰할 수 있는 구독 출처 또는 노드 provider	노드가 여전히 있는지, 인증 정보가 유효한지
로컬 수신 포트	클라이언트 설정 또는 명시적으로 지정한 덮어쓰기	실행 포트와 앱의 프록시 주소가 일치하는지
개인 도메인 규칙	로컬 규칙 확장 또는 직접 관리하는 설정	규칙 순서와 프록시 정책 이름이 올바른지
DNS와 TUN	관리 위치를 하나로 명확히 정하기	실행 값, 시스템 권한, 라우팅 설정이 서로 맞는지

규칙 순서는 특히 중요합니다. 일반적으로 규칙은 위에서부터 순서대로 적용됩니다. 새 도메인 규칙을 MATCH 뒤에 추가하면 해당 연결에 예상대로 적용되지 않습니다. 규칙 목록을 덮어쓸 때는 클라이언트가 목록 전체를 교체하는지, 목록의 앞이나 뒤에 추가하는지도 확인하세요. 구현 방식은 클라이언트마다 다르므로 서로 동일하다고 가정하면 안 됩니다.

수정하기 전에 정상 작동하는 설정을 백업하고 클라이언트 이름, 코어 버전, 덮어쓰기 내용을 기록하세요. 한 번에 한 종류의 설정만 바꾸는 것이 좋습니다. 예를 들어 먼저 규칙을 수정한 다음 DNS를 변경하세요. 업데이트 후 문제가 생겨도 클라이언트 전체를 초기화하지 않고 구체적인 변경 사항만 되돌릴 수 있습니다.

자주 묻는 질문과 정리 목록

구독 업데이트는 성공했는데 노드가 바뀌지 않은 이유는 무엇인가요?

출처에서 제공하는 내용 자체가 바뀌지 않았거나, 노드가 별도의 provider에서 제공되어 해당 provider를 업데이트해야 할 수 있습니다. 현재 활성화된 Profile을 업데이트했는지, 목록에 있는 예비 설정을 업데이트한 것은 아닌지도 확인하세요. 클라이언트에 표시된 업데이트 시각만으로 노드가 실제로 바뀌었다고 판단할 수는 없습니다.

설정을 가져오는 데 성공했는데 연결되지 않는 이유는 무엇인가요?

가져오기, 파싱, 설정 로드, 실제 연결은 서로 다른 단계입니다. 로그에서 설정이 정상적으로 로드되었는지, 프록시 그룹에서 사용할 수 있는 노드를 선택했는지, 7890 등 실제 포트가 열려 있는지, 앱이 시스템 프록시나 TUN을 통해 트래픽을 보내는지 차례대로 확인하세요. 노드 지연 시간 테스트에 성공해도 모든 웹사이트에 같은 정책이 적용되는 것은 아닙니다.

구독 두 개를 하나로 합칠 수 있나요?

지원되는 설정 병합 기능이나 직접 관리하는 provider를 사용하면 노드를 한데 구성할 수 있지만, YAML 파일 두 개를 단순히 이어 붙여서는 안 됩니다. 같은 이름의 최상위 필드, 중복 노드 이름, 프록시 그룹 참조, 규칙 순서를 조정해야 합니다. 처음에는 Profile 두 개를 따로 유지하고 용도에 따라 전환하는 편이 확인과 복구에 쉽습니다.

다른 기기로 옮길 때 무엇을 복사해야 하나요?

설정 파일뿐 아니라 구독 출처, 업데이트 주기, 로컬 덮어쓰기 내용도 기록하세요. 이전한 뒤 포트, 시스템 프록시, TUN 권한을 다시 확인해야 합니다. 데스크톱 플랫폼의 경로, 네트워크 인터페이스 이름, 라우팅 설정을 휴대폰에 그대로 적용해서는 안 됩니다. 파일을 복사하기 전에 저장 위치와 전송 방식이 계정 인증 정보를 안전하게 다룰 수 있는지 확인하세요.

일상용, 예비용, 테스트용 설정을 각각 하나씩 유지하고 더 이상 필요 없는 복사본은 정리하세요.
원격 설정에는 출처와 업데이트 주기를 기록하고, 로컬 설정에는 수정 날짜와 용도를 기록하세요.
업데이트 후 설정 로드 결과를 확인하고, 전환 후에는 새 연결에 적용된 규칙과 최종 정책을 확인하세요.
수정 전에 백업하세요. 문제가 생기면 먼저 마지막으로 정상 작동한 설정으로 돌아간 다음 구체적인 차이를 확인하세요.

Profile 관리의 핵심은 출처, 설정 내용, 실행 상태를 구분하는 것입니다. 원격 업데이트와 로컬 변경 사항을 따로 관리하고, 설정 전환 후 연결을 확인하면 노드 변경, 클라이언트 업그레이드, 기기 이전에도 설정을 추적하고 되돌리기 쉽습니다.