Clash Profile이란? 구독 설정·로컬 YAML·여러 설정 전환 가이드

Profile은 노드 하나가 아니라 설정 프로필입니다

Clash 클라이언트에서 Profile은 보통 선택하고 불러올 수 있는 설정 프로필을 뜻합니다. 구독 링크에서 가져오거나 디스크에 저장된 YAML 파일에서 불러올 수 있습니다. 클라이언트는 프로필 이름, 출처 주소, 업데이트 시간, 업데이트 정책 등의 관리 정보도 별도로 저장할 수 있습니다. 이 정보가 커널이 읽는 YAML에 반드시 포함되는 것은 아닙니다.

완전한 설정에는 수신 포트, DNS, 프록시 노드, 프록시 그룹, 라우팅 규칙 등이 포함될 수 있습니다. 노드는 그중 일부일 뿐입니다. 설정을 가져온 뒤 클라이언트에서 활성화해야 커널이 최종 설정에 따라 새 연결을 처리합니다. 구독 추가, 설정 활성화, 시스템 프록시 켜기는 서로 다른 상태입니다.

헷갈리기 쉬운 세 가지 작업

• 구독 업데이트: 기존 주소에서 내용을 다시 가져옵니다. 업데이트한다고 해당 설정이 자동으로 활성화되는 것은 아닙니다.
• Profile 전환: 현재 사용할 설정 출처를 바꿉니다. 프록시 그룹, 규칙, DNS도 함께 달라질 수 있습니다.
• 노드 전환: 현재 설정의 프록시 그룹에서 선택 항목을 바꿉니다. 보통 설정 전체를 바꾸는 작업은 아닙니다.

메뉴 이름은 클라이언트마다 다르며, ‘구독’, ‘설정’, ‘Profiles’ 등이 흔히 사용됩니다. 이 글에서는 설정 프로필을 통틀어 Profile이라고 부르며, 특정 클라이언트의 버튼 이름을 모든 제품에 공통되는 메뉴명처럼 사용하지 않습니다.

원격 구독, 로컬 YAML, 프록시 제공자의 차이

원격 구독은 가져오는 방식이고 YAML은 데이터 형식이므로 서로 대립되는 개념이 아닙니다. 원격 구독도 YAML을 반환할 수 있습니다. 로컬 파일을 가져오면 보통 클라이언트 내부에 사본이 저장됩니다. 원본 파일을 편집해도 클라이언트의 사본에는 반영되지 않을 수 있으니, 가져올 때 파일을 복사했는지 직접 참조했는지 확인해야 합니다.

구독 링크라고 해서 반드시 Clash 커널에서 바로 읽을 수 있는 것은 아닙니다. 노드 URI 목록만 있거나 웹 페이지 HTML, 로그인 페이지, 오류 메시지가 반환된다면 완전한 Clash 설정으로 불러올 수 없습니다. 가져오기 전에 구독 제공자가 Clash 또는 mihomo 호환 형식을 명시하는지, 클라이언트에서 어떤 커널을 사용하는지 확인하세요.

proxy-providers는 별도의 완전한 Profile이 아닙니다

이 기능을 지원하는 커널에서 기본 설정의 proxy-providers는 노드 출처를 정의하며, proxy-groups는 use로 제공자를 참조할 수 있습니다. 제공자에서 노드를 새로고침해도 기본 설정의 DNS, 규칙, 포트가 바뀌는 것은 아닙니다. 규칙 제공자인 rule-providers는 규칙 모음을 불러오며, 노드 제공자와 혼동해서는 안 됩니다.

처음 가져올 때는 형식을 확인한 뒤 활성화 상태를 점검하세요

1. 설치 파일 페이지에서 운영체제에 맞는 클라이언트를 선택하세요. 설정 호환성 문제를 확인할 때 필요하므로 클라이언트 버전과 커널 버전을 기록해 두세요.
2. 설정 관리 메뉴에서 원격 구독 주소를 추가하거나 로컬 .yaml, .yml 파일을 가져옵니다. 원격 주소는 전체를 붙여 넣고, 공백이나 줄바꿈, 메신저가 덧붙인 문장부호가 섞이지 않도록 하세요.
3. ‘일상-원격’, ‘업무-로컬’, ‘테스트-DNS’처럼 용도를 알아보기 쉬운 이름을 지정하세요. 이름은 관리용일 뿐, 같은 이름의 프록시 그룹이 자동으로 만들어지지는 않습니다.
4. 업데이트를 실행하고 결과를 확인하세요. 파싱에 실패하면 먼저 응답 내용과 형식부터 확인하세요. 시스템 프록시를 반복해서 켜고 끈다고 구문 오류가 해결되지는 않습니다.
5. 설정을 선택해 활성화한 다음 프록시 그룹과 규칙 목록이 불러와졌는지 확인하세요. 이후 시스템 프록시나 TUN을 켤지 결정하면 됩니다.

시스템 프록시는 시스템 프록시 설정을 따르는 앱이 로컬 프록시 포트를 통해 연결하도록 합니다. TUN은 가상 네트워크 인터페이스를 사용해 라우팅 조건에 맞는 트래픽을 처리합니다. 둘 다 설정을 가져오는 데 필수는 아니며, 노드 인증 오류를 자동으로 해결하지도 않습니다. TUN 사용 가능 여부는 커널, 운영체제 권한, 라우팅 설정에 따라 달라집니다.

포트는 클라이언트에 실제로 표시된 값을 기준으로 하세요. 아래 예시에서는 혼합 프록시 포트로 7890을 사용합니다. 이는 설정 예시일 뿐, 모든 클라이언트가 127.0.0.1:7890에서 수신한다고 단정할 수는 없습니다.

로컬 YAML 예시: 설정의 경계 이해하기

아래는 필드 간 관계를 이해하기 위한 로컬 설정 예시로, mihomo 환경에서 기본 구조를 확인하는 데 적합합니다. 이 설정에는 직접 연결만 있으며 원격 프록시 기능은 없습니다. local-direct.yaml로 저장한 뒤 가져오면 포트, 프록시 그룹, 규칙의 관계를 살펴볼 수 있습니다.

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

proxies: []

proxy-groups:
  - name: 수동 선택
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,수동 선택
  - MATCH,DIRECT

• mixed-port는 HTTP와 SOCKS 프록시가 함께 사용하는 수신 포트입니다. 다른 프로세스가 해당 포트를 사용 중이면 비어 있는 포트로 변경해야 합니다.
• allow-lan: false는 LAN 기기의 프록시 접근을 허용하지 않습니다. TUN 사용 여부와는 별개인 설정입니다.
• mode: rule은 규칙에 따라 트래픽을 분기한다는 뜻입니다. 예시 마지막의 MATCH,DIRECT는 앞에서 일치하지 않은 요청을 처리합니다.
• 수동 선택 그룹에는 DIRECT만 있으므로 이 그룹에 매칭되어도 직접 연결됩니다. 규칙에서 참조하는 그룹 이름은 정확히 일치해야 합니다.

YAML 들여쓰기에는 공백을 사용하고 Tab은 섞어 쓰지 마세요. false 같은 불리언 값은 문자열과 구분해야 하며, 목록 항목의 -도 그대로 유지해야 합니다. 파싱 오류가 발생하면 로그에 표시된 줄과 바로 윗줄부터 확인하세요. 흔한 원인은 들여쓰기 단계 오류, 콜론 누락, 닫히지 않은 따옴표입니다.

파싱에 성공했다고 인터넷에 연결되는 것은 아닙니다. 구문 검사가 끝난 뒤에도 노드 존재 여부, 프록시 그룹 참조의 유효성, 규칙이 의도한 출구와 일치하는지 각각 확인해야 합니다. Clash 원본, Clash Premium, Clash Meta(현 mihomo)는 기능 범위가 다르므로 파일 확장자만 보고 설정 호환성을 판단할 수 없습니다.

업데이트 주기: 구독 새로고침과 노드 상태 검사 구분하기

원격 Profile의 자동 업데이트는 대개 클라이언트가 관리합니다. 기본 설정의 HTTP 프록시 제공자는 interval로 업데이트 주기를 지정할 수 있으며, mihomo 관련 필드에서 값의 단위는 초입니다. 두 설정은 서로 다른 계층에서 작동하므로 하나를 설정하면 다른 하나도 자동으로 관리된다고 생각해서는 안 됩니다.

주기 환산 예시

• 3600초는 1시간입니다.
• 21600초는 6시간입니다.
• 86400초는 24시간입니다.

이 환산은 단위가 초인 필드에 적용됩니다. 클라이언트 화면에서는 분 단위 입력을 요구하거나 시간 옵션을 바로 제공할 수도 있으니 입력란에 표시된 단위를 확인하세요. 일반적인 설정은 구독 제공자가 권장하는 주기로 먼저 업데이트하면 됩니다. 별도 안내가 없다면 하루 한 번부터 시작해 노드 변경 빈도에 맞춰 조정하세요.

노드 상태 검사는 지정한 주소의 연결 가능 여부와 지연 시간을 확인할 뿐, 새 노드 목록을 내려받지는 않습니다. 목록에 작동하지 않는 노드가 나타나면 ‘상태 검사 실패’와 ‘구독 가져오기 실패’를 구분하세요. 전자는 연결 출구, 검사 주소, 시간 제한을 확인하고, 후자는 구독 주소, 네트워크 경로, 접근 권한, 응답 형식을 살펴봐야 합니다.

설정 오버라이드: 개인 설정과 원격 내용을 분리하기

원격 구독에서 내려받은 YAML을 직접 편집하면 다음 업데이트 때 변경 내용이 덮어써질 수 있습니다. 개인 규칙, DNS, 포트 설정처럼 계속 유지해야 하는 항목은 클라이언트가 지원하는 오버라이드, 병합 또는 스크립트 기능을 우선 사용하세요. 지원 기능은 클라이언트마다 다르며, Clash 커널이 모든 클라이언트 전용 오버라이드 파일 형식을 인식하는 것은 아닙니다.

먼저 최종 적용 설정을 확인하세요

설정이 불러와지는 과정을 ‘구독 원본 설정 → 클라이언트 병합 및 오버라이드 → 커널 실행 설정’으로 이해할 수 있습니다. 이는 문제를 진단하기 위한 관점이지, 모든 클라이언트에 고정된 처리 순서는 아닙니다. 일부 클라이언트는 화면 설정으로 설정 파일의 포트를 덮어쓰고, 일부는 전체 오버라이드와 Profile별 오버라이드를 구분합니다. 문제를 확인할 때는 구독 원문만 보지 말고 최종 실행 설정을 확인하세요.

1. 한 번에 하나씩 변경: 예를 들어 DNS, TUN, 모든 프록시 그룹을 동시에 바꾸지 말고 도메인 직접 연결 규칙 하나만 추가하세요.
2. 병합 방식을 확인: 목록은 기존 항목을 대체하거나, 앞에 넣거나, 뒤에 추가할 수 있습니다. 규칙은 순서대로 적용되므로 새 규칙을 기본 처리 규칙인 MATCH 뒤에 추가하면 보통 기대한 결과를 얻지 못합니다.
3. 참조 이름 확인: 사용자 지정 규칙이 가리키는 프록시 그룹은 병합 후 설정에 실제로 존재해야 합니다.
4. 새로고침 후 재확인: 구독을 수동으로 한 번 업데이트한 뒤 새 규칙이 남아 있는지, 순서는 올바른지 확인하세요.

여러 Profile에서 오버라이드를 공유할 때는 특히 주의하세요. 설정 A에 ‘수동 선택’ 그룹이 있어도 설정 B에 같은 그룹이 있다는 보장은 없습니다. 공유 규칙이 이 이름에 의존한다면 전환 후 유효하지 않은 참조가 생길 수 있습니다. 직접 관리하는 그룹 이름을 통일하거나 Profile마다 별도 오버라이드를 설정하세요. 출처가 다른 설정에 하나의 수정 스크립트를 억지로 적용하지 않는 편이 좋습니다.

여러 설정 전환: 하나는 활성화하고 나머지는 보관하기

일반적인 단일 인스턴스 클라이언트는 기본 Profile 하나를 선택한 뒤 자체 지원 오버라이드를 적용합니다. 구독 세 개를 추가해도 규칙 세 개가 자동으로 병합되거나 모든 노드가 하나의 프록시 그룹에 함께 표시되는 것은 아닙니다. 노드를 통합해야 한다면 설정 목록 순서에 기대지 말고 기본 설정과 프록시 제공자의 구성을 명확히 설계하세요.

용도가 분명한 프로필 세 개를 유지하세요

• 일상용 설정: 안정적인 출처를 사용하고 자동 업데이트를 켜 기본 설정으로 사용합니다.
• 백업 설정: 출처와 접근 경로를 별도로 확인하고 정기적으로 수동 업데이트하세요. 급히 필요할 때 이미 사용할 수 없는 상태가 되는 일을 예방할 수 있습니다.
• 테스트 설정: DNS, 규칙, TUN 매개변수를 확인합니다. 불필요한 자동 업데이트를 끄면 변경 전후를 비교하기 쉽습니다.

전환하기 전에 현재 설정 이름, 모드, 프록시 그룹 선택, 포트를 기록하세요. 전환한 뒤 새 설정이 규칙 모드를 사용하는지, DNS, LAN 접근, TUN 설정이 달라졌는지 확인하세요. 클라이언트가 일부 전역 스위치 상태를 유지할 수 있으므로 Profile을 바꿔도 모든 설정이 초기화되는 것은 아닙니다.

기존 연결은 설정 전환 직후 새 출구로 바뀌지 않을 수 있습니다. 동작은 클라이언트의 다시 불러오기 방식과 연결 종료 여부에 따라 달라집니다. 확인할 때는 새 요청을 보내세요. 필요한 경우 클라이언트에서 기존 연결을 끊거나 대상 앱을 다시 시작하세요. 계속 전송 중인 다운로드 하나만 보고 전환 성공 여부를 판단하지 마세요.

백업 및 복원: 출처, 오버라이드, 실행 조건 저장하기

YAML만 백업해서는 클라이언트를 완전히 복원하기 어려운 경우가 많습니다. 원격 주소, 업데이트 주기, 오버라이드 파일, 화면의 전역 설정이 클라이언트 데이터베이스나 설정 디렉터리에 각각 저장될 수 있습니다. 이전하기 전에 클라이언트가 지원하는 내보내기 기능을 우선 사용하고, 내보낸 파일에 민감한 정보가 포함되는지 확인하세요.

1. 출처 저장: 구독 관리 위치, 설정 이름, 업데이트 주기를 기록하세요. 토큰이 포함된 링크는 보호된 저장소에 보관하세요.
2. 로컬 파일 저장: 로컬 YAML, 오버라이드 스크립트, 직접 관리하는 규칙 파일을 백업하세요. 상대 경로에 의존하는 설정이라면 디렉터리 구조도 유지해야 합니다.
3. 실행 조건 기록: 클라이언트 및 커널 버전, 실제 수신 포트, 시스템 프록시 상태, TUN 설정을 기록하세요.
4. 복원 테스트: 먼저 설정을 가져온 뒤 오버라이드를 불러오세요. 로그에 파싱 오류나 참조 오류가 없는지 확인하고 마지막으로 새 연결을 테스트하세요.

파일 이름은 daily-2026-08-27.yaml, override-2026-08-27.yaml처럼 지정하면 출처와 날짜를 쉽게 확인할 수 있습니다. 백업은 캐시를 영구적으로 유효한 구독으로 간주하는 것이 아닙니다. 노드 인증 정보가 만료될 수 있으므로 복원한 뒤에도 원격 출처에서 다시 가져오고 연결을 확인해야 합니다.

자주 묻는 질문: 업데이트·전환·복원 문제

여러 Profile을 관리할 때는 네 가지를 구분해야 합니다. 설정의 출처, 개인 수정 사항의 저장 위치, 현재 활성화된 설정, 커널이 최종적으로 불러온 내용입니다. 이 네 가지를 차례로 확인하면 업데이트로 인한 덮어쓰기, 전환 오류, 이전 과정에서 설정이 사라지는 문제를 대개 구체적인 단계까지 좁힐 수 있습니다.