Clash Profile이란? 설정 파일 기본 개념과 여러 설정 전환·관리

Profile, config.yaml, 실행 설정

Profile은 클라이언트에서 관리하는 설정 프로필입니다. 로컬 YAML 파일이나 원격 구독 주소를 통해 가져올 수 있습니다. 설정 내용 외에도 이름, 출처, 업데이트 시각 같은 관리 정보가 함께 저장되는 경우가 많습니다. Profile을 전환하면 설정 출처와 내용이 바뀌며, 클라이언트를 다시 설치하거나 운영체제의 네트워크 설정을 바꾸는 것은 아닙니다.

config.yaml은 흔히 쓰이는 설정 파일 이름일 뿐, 모든 Profile이 공유하는 고정된 파일을 뜻하지는 않습니다. Clash 또는 mihomo 코어를 직접 실행할 때는 사용할 설정 파일을 지정할 수 있습니다. Clash Nyanpasu에서는 구독 내용, 클라이언트 설정, 오버라이드 처리를 조합해 코어에 전달할 실행 설정을 만들 수 있습니다. 따라서 설정 목록에 표시되는 원본과 코어가 실제로 읽는 내용은 완전히 같지 않을 수 있습니다.

항목	주요 내용	확인 위치
Profile	이름, 출처, 설정 본문 및 관리 정보	클라이언트의 ‘프로필’ 페이지
원본 YAML	노드, 프록시 그룹, 규칙 및 기타 설정 항목	설정 편집기 또는 내보낸 원본 파일
실행 설정	클라이언트가 처리한 뒤 코어에 전달하는 설정 항목	실행 설정 보기 메뉴 및 코어 로그
클라이언트 설정	시스템 프록시 스위치, UI 옵션 및 클라이언트 관리 매개변수	클라이언트의 ‘설정’ 페이지

문제를 진단할 때는 먼저 어느 계층을 수정했는지 확인하세요. 원본 YAML을 수정해도 적용되지 않는다면 다시 불러오지 않았거나, 같은 이름의 설정 항목이 클라이언트 설정이나 오버라이드에 의해 바뀌었을 수 있습니다. 임시로 생성된 실행 파일을 수정해 당장은 반영되더라도, 다음 전환·업데이트·재시작 때 파일이 다시 만들어질 수 있습니다.

로컬 설정, 원격 구독, 오버라이드의 역할

로컬 설정: 고정된 입력으로 재현하기 편리

로컬 설정은 규칙을 시험하거나 문제를 재현하고, 오프라인으로 보관할 때 적합합니다. 가져온 뒤 클라이언트가 파일 내용을 복사하는지, 원본 파일을 참조하는지 확인하세요. 바탕 화면의 원본 파일을 수정하면 클라이언트에도 자동으로 반영된다고 단정할 수 없습니다. 이름을 바꾼 파일을 다시 가져온 뒤 내용을 비교하면 클라이언트의 관리 방식을 확인할 수 있습니다.

원격 구독: 주기적으로 가져오는 설정 출처

원격 Profile에는 보통 구독 URL이 저장되며, 수동 또는 예약 업데이트 시 설정 내용을 다시 가져옵니다. 구독에서 완전한 Clash YAML을 반환한다면 proxies, proxy-groups, rules를 함께 제공할 수 있습니다. 노드 URI만 담긴 텍스트는 완전한 Clash 설정 파일과 다릅니다. 파일 확장자를 .yaml로 바꾸는 것만으로 변환할 수는 없습니다.

원격 Profile의 노드나 규칙을 직접 수정하면 다음 업데이트에 유의해야 합니다. 업데이트 과정에서 원본 내용이 교체되면 수동으로 한 수정도 사라집니다. 개인 규칙을 장기간 유지하려면 별도의 오버라이드 계층에 두거나 구독을 로컬 Profile로 저장해 관리하세요. 후자는 원래 구독의 변경 사항을 자동으로 가져오지 않습니다.

오버라이드 스크립트: 개인 설정 차이 유지

오버라이드는 입력 설정에 항목을 추가하거나 조정할 때 사용합니다. 예를 들어 LAN 연결 규칙을 추가하거나 로그 수준을 통일할 수 있습니다. 사용할 수 있는 병합 방식, 스크립트 API, 처리 순서와 적용 범위는 클라이언트 버전에 따라 다릅니다. 다른 클라이언트의 스크립트를 Clash Nyanpasu에서도 통용되는 API로 간주하지 말고, 목록 항목이 항상 뒤에 추가된다고 가정하지 마세요.

검증 가능한 로컬 Profile 만들기

아래 YAML은 가져오기, 전환, 규칙 로드를 확인하기 위한 예제로 프록시 서버는 포함하지 않습니다. UTF-8 인코딩으로 local-check.yaml에 저장한 다음 ‘프로필’ 페이지의 로컬 파일 가져오기 메뉴에서 추가하세요. 해당 Profile을 선택하고 로드 상태를 확인합니다. 메뉴 이름은 버전에 따라 달라질 수 있으므로 현재 화면의 파일 가져오기 기능을 이용하세요.

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

proxy-groups:
  - name: Local-Choice
    type: select
    proxies:
      - DIRECT
      - REJECT

rules:
  - DOMAIN,example.com,DIRECT
  - MATCH,Local-Choice

mixed-port: 7890은 이 예제에서 HTTP와 SOCKS가 함께 사용하는 포트입니다. 모든 클라이언트 버전의 기본 포트라는 뜻은 아닙니다.
allow-lan: false는 LAN 연결을 제한합니다. 이 예제를 LAN 공유 프록시 설정으로 사용하지 마세요.
mode: rule은 규칙 모드를 뜻합니다. 클라이언트에서 모드를 별도로 관리한다면 UI에 표시된 현재 값과 실제 실행 값을 확인하세요.
Local-Choice에는 기본 제공 대상인 직결과 차단만 있습니다. 가져오기에 성공해도 원격 프록시를 사용할 수 있는 것은 아닙니다.

로드한 뒤 프록시 그룹 페이지에서 Local-Choice가 있는지 확인하고 DIRECT를 선택하세요. 로컬 HTTP 프록시 포트를 확인하려면 아래 명령을 실행할 수 있습니다. 이 테스트는 시스템 프록시 스위치와 무관하며, 브라우저의 모든 트래픽이 프록시를 통과한다는 뜻도 아닙니다.

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

명령 결과를 확인하면서 연결 기록도 살펴보세요. example.com은 도메인 직결 규칙에 매칭되어야 합니다. 포트 연결이 거부되면 구독 문제로 단정하지 말고 코어 실행 상태와 실제 수신 포트를 먼저 확인하세요.

여러 설정의 이름 짓기와 전환 방법

출처·용도·상태로 Profile 구분하기

이름만 봐도 설정의 범위를 알 수 있어야 합니다. ‘출처-용도-상태’ 형식을 권장합니다. 예: 구독A-일상-안정, 로컬-규칙 검증-테스트, 구독B-예비-확인 필요. 이름에 전체 구독 URL이나 계정 토큰은 넣지 마세요. 날짜는 백업 파일명에 넣으면 설정 목록에 비슷한 이름이 매일 늘어나는 것을 막을 수 있습니다.

현재 상태를 기록합니다.현재 Profile, 선택한 프록시 그룹 노드, 규칙 모드, 실제 포트, 시스템 프록시와 TUN 스위치 상태를 적어 두세요. 예를 들어 포트가 7890이라면 전환 후 수신 포트가 달라질 때 프록시를 수동 설정한 앱도 함께 변경해야 합니다.
대상 Profile을 확인합니다.원격 Profile은 먼저 업데이트해 설정을 정상적으로 가져왔는지 확인하세요. 로컬 Profile은 YAML 들여쓰기와 규칙 대상을 확인하고, 참조하는 프록시 그룹이 실제로 있는지 살펴보세요.
Profile을 전환합니다.‘프로필’ 페이지에서 대상 Profile을 선택하고 클라이언트의 로드가 끝날 때까지 기다리세요. 코어 로그에 파싱 오류, 지원하지 않는 설정 항목, 포트 충돌이 없는지 확인합니다.
프록시 그룹을 다시 확인합니다.두 Profile에 ‘프록시’라는 이름의 그룹이 있어도 그룹 구성원은 다를 수 있습니다. 그룹 이름만 보고 판단하지 말고 현재 선택된 노드를 확인하세요.
새 연결로 검증합니다.새 웹 요청을 보내고 연결 기록에서 규칙, 프록시 체인, 대상이 올바른지 확인하세요. Profile 카드가 선택된 것만으로는 트래픽 경로가 정상이라고 판단하기 어렵습니다.

Profile 전환은 보통 이후에 생성되는 연결부터 적용되며, 이미 연결된 세션이 즉시 옮겨가지는 않을 수 있습니다. 정확하게 검증하려면 테스트 앱을 종료했다가 다시 열거나 클라이언트의 연결 종료 기능을 사용하세요. 연결을 종료하면 다운로드, 회의, 장시간 연결이 끊길 수 있으니 먼저 작업을 저장하세요.

여러 Profile, 여러 노드, TUN의 차이

하나의 Profile에 여러 노드를 포함하고 select, url-test 같은 프록시 그룹으로 구성할 수 있습니다. 노드 A에서 노드 B로만 바꾸려면 보통 새 Profile을 만들 필요가 없습니다. 규칙 전체, DNS 설정 또는 구독 출처를 바꿔야 한다면 Profile 전환을 고려하세요.

일반적인 데스크톱 클라이언트 인스턴스는 현재 코어에 최종 실행 설정 하나를 전달합니다. 목록에 Profile이 세 개 있다고 해서 세 Profile의 규칙이 자동으로 동시에 합쳐지는 것은 아닙니다. 여러 출처를 결합하려면 명시적으로 지원되는 설정 결합 기능을 사용하고 노드 이름, 프록시 그룹 이름, 규칙 대상이 충돌하지 않는지 확인하세요.

트래픽 가로채기와 설정 선택은 별개입니다

시스템 프록시:운영체제의 프록시 설정을 따르는 앱에 영향을 줍니다. 일부 프로그램은 자체 프록시 설정을 사용하거나 시스템 프록시를 무시합니다.
TUN 모드:가상 네트워크 인터페이스와 관련 라우팅을 통해 트래픽을 가로챕니다. 운영체제 권한과 올바른 DNS·라우팅 설정이 필요합니다.
Profile:코어가 연결을 처리할 때 사용할 노드, 규칙, 관련 매개변수를 제공합니다. 앞서 설명한 트래픽 가로채기 스위치와는 다릅니다.

Profile을 전환한 뒤에도 특정 앱이 여전히 직결된다면, 먼저 해당 앱의 연결이 코어 기록에 나타나는지 확인하세요. 기록에 없다면 트래픽 가로채기 방식을 먼저 점검하고, 기록은 있지만 잘못된 대상으로 연결된다면 모드, 규칙 순서, 프록시 그룹 선택을 확인하세요. 규칙 매칭 문제를 해결하려고 TUN을 계속 켜고 끄지는 마세요.

오버라이드 최소 변경과 호환성 확인

장기간 사용할 오버라이드는 범위를 좁히고 대상을 명확히 유지하세요. 예를 들어 구독 전체를 복사해 항목마다 바꾸기보다 LAN 직결 규칙 하나만 추가하는 편이 좋습니다. 규칙 대상은 실제로 존재하는지 확인한 그룹 이름을 참조하세요. Profile마다 그룹 이름이 다르면 각각 별도로 설정하거나, 처리 로직에서 대상의 존재 여부를 명시적으로 확인해야 합니다.

# rules 목록 앞부분에 삽입하고 MATCH 뒤에는 두지 않기
- IP-CIDR,192.168.50.0/24,DIRECT,no-resolve

이 코드는 규칙 일부일 뿐, 단독으로 가져올 수 있는 완전한 Profile이 아닙니다. 예시 대역인 192.168.50.0/24에만 적용됩니다. 실제 LAN 대역이 192.168.1.0/24라면 라우팅 테이블에 맞게 수정해야 합니다. no-resolve는 이 IP 규칙을 매칭하기 위해 도메인을 별도로 조회하지 않는다는 뜻이지, 모든 DNS 조회를 끄는 설정은 아닙니다.

안정적으로 작동하는 Profile의 복사본에서 먼저 테스트하고, 원본은 되돌릴 수 있도록 보관하세요.
한 번에 한 종류의 항목만 변경하세요. 예를 들어 먼저 규칙을 수정하고 DNS는 나중에 변경하며, 포트와 TUN을 동시에 조정하지 마세요.
최종 실행 설정을 확인해 항목 값, 목록 순서, 규칙 대상이 의도한 대로인지 점검하세요.
구독을 한 번 업데이트한 뒤 다시 확인해 개인 설정이 오버라이드를 통해 계속 적용되는지 검증하세요.

Clash, Clash Meta(mihomo) 및 각 버전은 지원하는 설정 항목이 완전히 같지 않습니다. ‘알 수 없는 설정 항목’이나 지원되지 않는 규칙 유형 오류가 발생하면 먼저 코어 이름과 버전을 기록한 뒤 YAML 가이드에서 호환성을 확인하세요. Profile 파일 이름만 바꿔서는 코어 기능 차이를 해결할 수 없습니다.

설정 백업 및 복원 순서

백업할 항목은 YAML 파일 하나로 끝나지 않습니다

복원 가능한 백업에는 설정 본문, 오버라이드 내용, 필요한 클라이언트 설정 기록이 포함되어야 합니다. 원격 URL도 저장하되 별도로 암호화해 보관하세요. 구독 링크만 백업하면 구독 서비스에서 나중에 삭제된 노드를 보존할 수 없습니다. 원본 YAML만 백업하면 실제 적용된 개인 오버라이드를 놓칠 수도 있습니다.

원본 설정:안정적으로 작동하는 Profile을 local-check-2026-09-27.yaml처럼 내보내세요.
오버라이드와 연결 정보:스크립트, 규칙 조각, 적용 대상 Profile을 기록한 설명을 저장하세요.
환경 정보:클라이언트 및 코어 버전, 수신 포트, 시스템 프록시와 TUN 상태를 기록하세요.
민감 정보:구독 토큰, 노드 비밀번호, 제어 인터페이스 키, 인증서 파일을 확인하고 공개 저장소에 올리지 않도록 주의하세요.

복원할 때는 먼저 원본 설정을 가져와 정상적으로 파싱되는지 확인합니다. 다음으로 오버라이드를 복원하고 최종 설정 항목을 점검한 뒤, 필요에 따라 시스템 프록시나 TUN을 켜세요. 다른 컴퓨터로 복원할 때는 이전 컴퓨터의 네트워크 인터페이스 이름, 절대 경로, LAN 주소를 그대로 적용하지 마세요. 규칙 세트와 프록시 제공자가 원격 다운로드에 의존한다면 새 컴퓨터에서 필요한 콘텐츠를 가져올 수 있는지도 확인해야 합니다.

자주 발생하는 문제의 점검 순서

증상	먼저 확인할 항목	해결 방법
전환했는데도 이전 설정처럼 보임	로드 로그, 현재 실행 규칙, 기존 연결	로드 성공 여부를 확인한 다음 새 연결로 테스트
구독 업데이트 후 규칙이 사라짐	원격 원본 내용을 직접 수정했는지 여부	개인 설정 차이를 오버라이드 또는 로컬 Profile로 옮기기
프록시 그룹이 없다는 메시지가 표시됨	규칙 대상과 그룹 이름이 완전히 일치하는지 여부	대소문자, 공백, 구독 업데이트 후 바뀐 그룹 이름 확인
코어가 시작되지 않음	첫 번째 파싱 오류, 설정 호환성, 포트 충돌	안정적으로 작동하는 Profile로 되돌린 다음 변경 사항을 하나씩 복원
일부 앱에서만 작동하지 않음	연결이 코어에 들어오는지, 앱 자체 프록시 설정 여부	먼저 트래픽 경로를 확인한 뒤 규칙 매칭 점검

안정적으로 관리하려면 되돌릴 수 있는 Profile을 하나 보관하고, 구독 출처와 개인 수정을 분리한 다음 전환 후 실행 상태를 확인하세요. 설정 파일은 트래픽 처리 방식을 정의하고, 클라이언트는 설정을 구성하고 불러오며, 시스템 프록시나 TUN은 트래픽을 코어로 전달합니다. 이 세 계층을 나눠 점검하면 구독을 반복해서 가져오는 것보다 문제를 쉽게 찾을 수 있습니다.