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

Profile, 구독 링크, 실행 설정

Clash 계열 클라이언트에서 Profile은 일반적으로 저장하고 업데이트한 뒤 활성화할 수 있는 설정 프로필을 뜻합니다. 화면에는 ‘설정’, ‘구독’ 또는 ‘Profiles’로 표시될 수 있습니다. 단일 노드나 독립적인 프록시 프로토콜을 의미하는 것은 아닙니다. mihomo 코어에서 실제로 사용하는 것은 클라이언트가 최종 전달하는 설정 내용으로, 노드, 정책 그룹, 규칙, DNS, 수신 포트 등의 설정이 포함됩니다.

구독 링크는 원격 콘텐츠를 가져오는 주소입니다. 클라이언트가 해당 주소에 접속해 응답을 로컬 설정으로 저장한 다음, 검사와 로드를 진행합니다. 따라서 링크, 다운로드한 파일, 코어가 현재 실행 중인 설정은 서로 다른 단계입니다. 화면에 구독 항목을 추가했다고 해서 활성화된 것은 아닙니다. 파일 다운로드에 성공해도 현재 코어가 모든 필드를 지원한다는 뜻은 아닙니다.

객체	저장 내용	주요 용도
구독 링크	원격 주소, 보통 액세스 인증 정보 포함	서버에서 제공하는 설정을 다시 가져오기
원격 Profile	다운로드한 설정 및 업데이트 관련 정보	출처를 유지하며 필요할 때 또는 정기적으로 업데이트
로컬 Profile	직접 만들거나 가져온 YAML 파일	노드, 규칙, 설정 구조를 직접 관리
실행 설정	클라이언트가 처리해 코어에 전달한 결과	현재 연결의 이름 해석 및 아웃바운드 방식 결정

전체 설정과 노드 구독의 차이

‘구독’이라고 표시된 모든 응답을 완전한 Profile로 바로 사용할 수 있는 것은 아닙니다. 전체 mihomo 설정에는 proxies, proxy-groups, rules 등의 필드가 포함될 수 있습니다. 노드만 포함된 리소스는 proxy-providers에서 사용할 수 있습니다. 다른 형식의 노드 목록은 클라이언트가 해당 가져오기 또는 변환 기능을 지원해야 합니다. 파일 확장자만으로 호환 여부를 판단할 수는 없습니다.

원격 설정과 로컬 YAML의 관리 범위

원격 설정: 주요 내용은 제공처에서 관리

원격 Profile은 노드 변경이나 서버 측 규칙 조정을 계속 받아야 할 때 적합합니다. 일반적인 경로는 ‘설정’ → ‘새로 만들기’ 또는 ‘가져오기’ → ‘URL’입니다. 제공처의 호환 링크를 붙여 넣고 다운로드한 다음 선택해 활성화하세요. 클라이언트마다 메뉴 이름은 다르므로 현재 버전의 화면을 기준으로 항목의 출처 유형과 활성화 상태를 확인하세요.

원격 설정을 다운로드한 사본에서 직접 수정하면 업데이트 시 덮어써질 수 있습니다. 다음 업데이트에서 노드, 정책 그룹, 규칙이 다시 생성되며 직접 추가한 도메인 규칙이 사라질 수 있습니다. 수정 사항을 장기간 유지하려면 클라이언트가 제공하는 오버라이드, 병합 또는 스크립트 기능을 우선 사용하세요. 이러한 기능은 클라이언트 계층에서 제공되며, 모든 mihomo 클라이언트가 동일하게 구현하는 것은 아닙니다.

로컬 설정: 파일 자체를 직접 관리

로컬 YAML은 규칙 테스트, 오프라인 보관, 특정 상황에 맞춘 설정에 적합합니다. 처음에 구독에서 가져온 파일이라고 해도 자동으로 업데이트되지는 않습니다. 파일 안에서 원격 provider를 사용하는 경우 해당 리소스는 자체 설정에 따라 새로고침될 수 있습니다. 이는 로컬 Profile 전체가 원격 설정으로 교체되는 것과는 다릅니다.

아래는 구조를 살펴보기 위한 직결 설정입니다. 원격 노드가 없으므로 프록시 서비스로 사용할 수 없습니다. 예시는 7890 혼합 포트를 수신하며 HTTP와 SOCKS 클라이언트의 연결을 허용합니다. 규칙에 따라 트래픽을 선택 가능한 정책 그룹으로 전달합니다.

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

proxies: []

proxy-groups:
  - name: 일상 아웃바운드
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,일상 아웃바운드

proxies에는 인라인 노드가 저장됩니다. 예시에서는 빈 목록이므로 사용할 수 있는 프록시 노드가 없습니다.
proxy-groups는 아웃바운드 항목을 정책 그룹으로 구성합니다. 규칙에서 참조하는 그룹은 실제로 존재해야 하며 이름도 정확히 일치해야 합니다.
rules는 위에서 아래로 순서대로 적용됩니다. 위쪽의 도메인 규칙이 먼저 적용되고, 마지막 MATCH가 나머지 트래픽을 처리합니다.
mode: rule은 규칙 모드를 사용한다는 뜻이며, 운영체제의 시스템 프록시나 TUN을 자동으로 활성화하지는 않습니다.

원본 파일과 실제 적용 설정 구분하기

일부 클라이언트는 화면 설정으로 포트, DNS, TUN을 제어한 다음 해당 값을 Profile에 병합합니다. 이 경우 원본 파일에 mixed-port: 7890이 있어도 실제 실행 설정에서는 화면에 지정된 다른 포트를 사용할 수 있습니다. 값이 일치하지 않으면 원본 파일을 반복해서 수정하기보다 클라이언트의 ‘실행 설정’, ‘유효 설정’ 또는 관련 로그를 확인하세요.

구독 업데이트 주기와 리소스 새로고침

원격 Profile 전체를 정기적으로 다운로드하는 작업은 일반적으로 클라이언트가 담당합니다. proxy-providers와 rule-providers의 리소스 새로고침은 mihomo가 각각의 interval에 따라 수행할 수 있습니다. 서로 다른 타이머이므로 한쪽이 업데이트된다고 다른 쪽도 함께 바뀌는 것은 아닙니다.

업데이트 단계	설정 위치	주기 의미
원격 Profile	클라이언트의 구독 항목 설정	화면에 분 또는 시간 단위로 표시될 수 있으니 단위를 확인하세요
HTTP 프록시 provider	해당 proxy-providers 항목	interval은 보통 초 단위이며 3600은 1시간입니다
HTTP 규칙 provider	해당 rule-providers 항목	interval은 초 단위이며 86400은 24시간입니다

제공처 업데이트 주기에 맞게 설정하기

먼저 ‘설정’ → 해당 구독 항목 → ‘편집’ 또는 ‘설정’에서 업데이트 활성화 여부와 시간 단위를 확인하세요.
제공처의 별도 안내가 없다면 원격 Profile 업데이트 주기를 24시간으로 시작한 뒤 노드 변경 빈도에 맞춰 조정할 수 있습니다. 이는 관리 권장 사항이며 코어의 기본값은 아닙니다.
수동으로 한 번 업데이트하고 완료 시간과 오류 메시지를 확인한 다음 설정이 다시 로드됐는지 확인하세요.
기기가 절전 모드에 들어가면 예약 작업이 계속 실행된다고 가정하지 마세요. 네트워크 복구 후 마지막 업데이트 시간을 확인하고 필요하면 직접 새로고침하세요.

연결 문제를 해결하려고 매분 구독을 가져오지 마세요. 요청 빈도가 너무 높으면 제공처의 제한에 걸릴 수 있으며, 잘못된 비밀번호, DNS 장애, 규칙 오적용도 해결하지 못합니다. 업데이트는 ‘설정 내용이 오래됐는지’를 확인하는 작업이고, 연결 로그는 ‘이번 요청이 어떤 경로로 처리됐는지’를 확인하는 자료입니다.

업데이트는 성공했지만 노드가 바뀌지 않음

먼저 업데이트한 항목이 현재 활성화된 설정인지 확인하세요. 목록에서 이름이 비슷한 다른 설정일 수 있습니다. 다음으로 노드가 인라인 목록에 있는지 provider에서 가져오는지 확인하세요. provider에 노드가 있다면 Profile을 다시 다운로드해도 동일한 provider 정의만 가져올 수 있습니다. 파일 다운로드 성공과 코어 재로드 성공도 구분해야 합니다. 클라이언트가 이전 설정을 계속 실행하면 네트워크는 정상이어도 새 내용이 적용되지 않은 상태일 수 있습니다.

오버라이드 규칙과 구독 업데이트 함께 사용하기

원격 노드는 제공처에서 관리하고 로컬 트래픽 분기 요구사항은 오버라이드 계층에 두는 방식이 장기적으로 관리하기 쉽습니다. 예를 들어 업무 서비스 도메인은 직결하고 나머지 트래픽은 구독 정책을 그대로 사용하려면 관련 규칙만 관리하면 됩니다. 원격 노드 목록 전체를 복사할 필요가 없습니다.

클라이언트에서 단일 Profile에만 병합 설정을 연결할 수 있는지, 아니면 모든 Profile이 전역 오버라이드를 공유하는지 확인하세요.
규칙이 삽입되는 위치를 확인하세요. 기존 MATCH 뒤에 추가한 규칙은 적용될 기회가 없습니다.
병합 방식을 확인하세요. 목록을 통째로 교체하는지, 앞이나 뒤에 추가하는지는 클라이언트 구현에 따라 다릅니다. YAML 병합이 규칙을 자동으로 이어 붙인다고 가정하지 마세요.
다시 로드한 뒤 유효 설정에서 규칙 순서와 참조된 정책 그룹 이름을 확인하세요.

예를 들어 DOMAIN-SUFFIX,example.com,DIRECT는 해당 도메인과 하위 도메인을 직결한다는 뜻입니다. 특정 요청을 구독의 정책 그룹으로 보내려면 구독에 실제로 존재하는 그룹 이름을 사용해야 합니다. 제공처에서 정책 그룹 이름을 바꾸면 오버라이드의 이전 이름도 함께 수정해야 합니다. 그렇지 않으면 설정 검사에 실패할 수 있습니다.

여러 설정을 함께 저장하고 상황별로 전환하기

Profile을 여러 개 저장해도 여러 설정이 동시에 활성화되는 것은 아닙니다. 대부분의 데스크톱 클라이언트는 하나의 코어 인스턴스에서 최종 설정 하나만 로드합니다. Profile을 전환하면 대개 규칙, 노드, 정책 그룹을 다시 로드하지만 이미 연결된 세션까지 즉시 전환된다고 보장할 수는 없습니다. 실제 동작은 클라이언트와 코어에 따라 다릅니다.

노드 수가 아니라 용도에 따라 이름 짓기

일상－원격: 안정적으로 사용하고 제공처의 업데이트 정책에 따라 관리합니다.
업무－로컬 규칙: 내부 서비스 접속 요구사항을 명확히 정리하고 필요한 DNS 및 라우팅 조건을 기록합니다.
테스트－로컬 사본: 규칙을 수정하고 새 필드를 검증하는 용도로 사용하며 일상 설정을 직접 덮어쓰지 않습니다.

백업 파일 이름은 daily-2026-09-09.yaml처럼 지정할 수 있습니다. 날짜를 붙이면 이전 설정으로 되돌리기 쉽지만 파일 이름에 구독 토큰을 포함하지 마세요. 각 설정에 출처, 업데이트 방식, 오버라이드 적용 범위도 기록하세요. 이런 메모가 ‘목록의 세 번째 항목’을 기억하는 것보다 확실합니다.

전환 후 확인할 다섯 가지

활성화 표시 확인: 대상 Profile을 선택하고 클라이언트 로드가 끝날 때까지 기다린 다음 설정 오류가 표시되는지 확인하세요.
정책 그룹 선택 확인: 이름이 같은 정책 그룹은 이전 선택을 복원할 수 있습니다. profile.store-selected와 같은 저장 설정이 있다면 특히 주의해서 확인하세요.
수신 포트 확인: 앱에서 127.0.0.1:7890을 직접 사용한다면 새 설정에 해당 연결 지점이 있어야 합니다. 없다면 앱 설정도 함께 변경하세요.
트래픽 처리 방식 확인: 시스템 프록시, TUN, DNS 상태를 확인하세요. Profile 전환만으로 운영체제의 네트워크 설정까지 반드시 바뀌는 것은 아닙니다.
새 연결 테스트: 대상 요청을 다시 실행하고 연결 기록에서 적용된 규칙과 아웃바운드 경로를 확인하세요. 필요하면 관련된 기존 연결을 끊은 뒤 테스트하세요.

업무 네트워크에서 전용 VPN을 사용한다면 TUN 라우팅과 내부 DNS의 충돌 여부도 확인해야 합니다. ‘공용 인터넷에 접속할 수 있음’만으로 전환이 성공했다고 판단하지 마세요. 내부 도메인이 제대로 조회되는지, 파일 서비스에 직접 연결할 수 있는지도 해당 환경의 확인 항목입니다.

자주 발생하는 문제와 복구 순서

가져온 뒤 YAML 구문 오류가 발생함

들여쓰기에 공백을 사용했는지, Tab 문자가 섞이지 않았는지, 콜론 뒤에 필요한 공백이 있는지 확인하세요. 다운로드한 내용의 첫 부분도 열어 보세요. <html>, 로그인 안내 또는 만료 안내가 표시된다면 링크가 예상한 설정 파일을 반환하지 않은 것입니다. 웹 페이지의 오류 내용을 YAML로 수정해 사용하지 마세요.

정책 그룹 또는 노드를 찾을 수 없다는 안내가 표시됨

proxy-groups, proxies, provider의 참조 관계를 대조하세요. 규칙의 대상 이름은 현재 존재하는 아웃바운드 항목으로 확인되어야 합니다. 최근 추가한 오버라이드를 먼저 되돌린 뒤 원본 설정을 불러와 문제가 구독 자체에서 비롯된 것인지 로컬 수정 때문인지 확인하세요.

업데이트 후 로드되지 않지만 이전 설정은 사용할 수 있음

이전 설정을 보관하고 모든 Profile을 먼저 삭제하지 마세요. 로그에서 로드 실패와 관련된 첫 번째 오류를 확인하고 현재 클라이언트 버전과 mihomo 코어 버전을 기록하세요. GUI 버전과 코어 버전은 서로 다릅니다. 새 필드를 지원하지 않는다면 유지보수 안내에 따라 호환되는 코어로 업그레이드하거나 이전에 작동한 설정을 복원하세요.

업데이트 연결이 시간 초과되거나 접근 오류가 반환됨

HTTP 401 또는 403은 보통 인증 정보, 권한 또는 서버 제한을 확인해야 한다는 뜻입니다. 429는 요청 빈도 제한을 나타냅니다. 시간 초과가 발생하면 네트워크와 DNS, 클라이언트가 구독을 가져올 때 직결과 프록시 중 어떤 방식을 사용하는지 확인하세요. 업데이트 요청이 현재 선택한 노드를 반드시 거친다고 가정하지 마세요.

사용 중인 노드가 이미 작동하지 않고 구독 다운로드도 해당 노드에 의존한다면 업데이트가 순환 의존 상태에 빠질 수 있습니다. 클라이언트가 허용하는 범위에서 제공처에 접속할 수 있는 업데이트 방식을 임시로 사용한 다음 새 설정을 가져오고 원래 방식으로 되돌리세요. 이 과정에서 구독 목록을 반복해서 비울 필요는 없습니다.

백업 및 일상 관리 체크리스트

최근에 정상 작동을 확인한 설정과 해당 설정에 적용되는 오버라이드 내용을 최소 한 벌 보관하세요.
원격 Profile과 로컬 테스트 파일의 이름을 구분해 업데이트 시 수동 규칙이 덮어써지지 않도록 하세요.
내보낸 파일에는 노드 비밀번호, 구독 주소, 제어 인터페이스 인증 정보가 포함될 수 있으므로 민감한 파일로 취급하세요.
기기를 옮길 때는 YAML만 복사하지 말고 포트 사용 여부, 파일 경로, TUN 권한, 시스템 프록시 설정도 다시 확인하세요.
중요한 변경을 할 때마다 활성 Profile, 정책 그룹 선택, 테스트 대상을 기록해 두면 같은 상태를 재현하거나 이전 설정으로 되돌리기 쉽습니다.

Profile 관리의 핵심은 출처, 수정 내용, 실행 상태를 분리하는 것입니다. 구독은 원격 콘텐츠를 제공하고, 로컬 파일이나 오버라이드는 환경별 요구사항을 유지하며, 유효 설정과 연결 기록은 실제 동작을 확인하는 근거가 됩니다. 이 세 계층을 구분해 두면 반복해서 재설치하지 않아도 정해진 절차에 따라 업데이트와 Profile 전환 문제를 점검할 수 있습니다.