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

Profile이란? 선택해서 사용하는 설정 프로필

Profile은 클라이언트가 설정을 관리할 때 사용하는 프로필 항목이며, 개별 노드 하나를 뜻하지 않습니다. 보통 설정 내용, 표시 이름, 출처 URL, 업데이트 시각이 기록됩니다. 클라이언트에 따라 메뉴 이름이 ‘설정’, ‘설정 파일’ 또는 ‘Profiles’로 표시될 수 있습니다. 항목을 선택하면 클라이언트가 해당 내용을 커널에 전달해 불러옵니다.

커널은 실제 연결을 처리하는 프로그램입니다. Clash와 Clash Meta(현재 명칭 mihomo)가 이 계층에 해당하며, 데스크톱 창이나 구독 목록, 업데이트 버튼은 클라이언트 인터페이스의 일부입니다. Profile 관리 방식은 클라이언트마다 다르므로, 이 글에서는 특정 인터페이스의 버튼 위치를 공통 기준으로 삼지 않고 작업 목적에 따라 설명합니다.

이름	실제 의미	주요 작업
Profile	클라이언트에서 관리하는 프로필 항목	이름 지정, 선택, 업데이트, 내보내기
구독 URL	원격 설정 또는 노드 데이터를 가져오는 주소	가져오기, 새로고침, 업데이트 주기 설정
로컬 YAML	기기에 저장된 텍스트 설정 파일	편집, 가져오기, 백업, 복원
노드	개별 프록시 연결에 필요한 설정 정보	연결 테스트, 프록시 그룹에 추가
프록시 그룹	규칙에서 참조하는 연결 옵션 모음	수동 선택, 정책에 따른 자동 선택

YAML은 들여쓰기로 계층 구조를 표현하는 텍스트 형식입니다. 전체 설정에는 보통 포트, 노드, 프록시 그룹, 규칙이 포함되지만, 구독 URL에서 내려받는 내용이 항상 완전한 설정인 것은 아닙니다. 노드 목록만 제공하는 주소도 있고, Base64로 인코딩된 데이터를 제공하거나 완전한 Clash YAML을 반환하는 주소도 있습니다. 파일 확장자가 설정 파일처럼 보인다고 해서 바로 사용할 수 있는 것은 아닙니다.

먼저 출처 구분하기: 구독 설정인가, 로컬 설정인가

구독 설정: 업데이트할 때 원격 데이터를 다시 가져옵니다

구독 설정은 서비스 제공자가 노드와 기본 규칙을 관리하는 경우에 적합합니다. 클라이언트에 출처 URL을 저장해 두고 업데이트를 실행하면 서버에 다시 요청합니다. 원격 내용이 바뀌면 로컬 캐시가 대체되는 경우가 많지만, 이전 사본을 보존하는지 설정을 어떻게 병합하는지는 클라이언트마다 다릅니다.

장점: 노드 추가·삭제나 연결 설정 변경 사항을 새로고침으로 반영할 수 있어 하나씩 수정할 필요가 없습니다.
주의: 내려받은 원본 설정을 직접 수정하면 다음 업데이트 때 변경 사항이 사라질 수 있습니다.
확인할 점: 항목에 출처 URL과 마지막 업데이트 시각이 표시되는지, 이번 업데이트가 성공했는지 확인하세요.

로컬 설정: 파일 내용을 직접 관리합니다

로컬 설정은 규칙을 익히거나 고정된 설정을 보관하고, 문제를 비교·진단할 때 유용합니다. 가져온 뒤 파일을 복사하는 클라이언트도 있고 지정된 경로의 파일을 읽는 클라이언트도 있습니다. 원본 파일을 수정하면 바로 적용된다고 단정하지 마세요. 편집 후 다시 불러오고 클라이언트가 실제로 어떤 파일을 사용하는지 확인해야 합니다.

로컬 설정에도 proxy-providers를 넣어 원격에서 노드를 가져올 수 있습니다. 따라서 ‘로컬 Profile’이 ‘원격 업데이트가 전혀 없음’을 뜻하지는 않습니다. 전체 설정 업데이트, 노드 제공자의 업데이트, rule-providers 규칙 제공자의 업데이트는 서로 다른 단계입니다.

첫 설정 가져오기: 형식과 활성화 상태 확인

가져오기에 성공한 것과 실제로 사용 중인 것은 다릅니다. 목록에 항목이 하나 추가됐다는 사실만으로는 클라이언트에 프로필이 등록됐다는 것만 알 수 있습니다. 구문 검사를 통과했는지, 활성화됐는지, 트래픽이 커널에 전달되는지는 각각 따로 확인해야 합니다.

클라이언트에서 ‘설정 / Profiles’ 페이지를 열고 원격 가져오기 또는 URL 가져오기를 선택하세요. 서비스 제공자가 Clash 또는 mihomo 형식이라고 명시한 구독 URL을 붙여 넣습니다.
새 항목의 이름을 일상-구독A로 지정하고, 기존에 사용 가능한 설정은 우선 삭제하지 마세요. ‘새 설정’처럼 모호한 이름보다 용도를 적으면 쉽게 구분할 수 있습니다.
한 번 업데이트한 뒤 결과를 확인하세요. 형식 오류가 표시되면 응답 내용이 로그인 페이지나 만료 안내, 또는 다른 형식의 구독 데이터는 아닌지 살펴보세요.
해당 항목을 선택하고 활성화하거나 전환하세요. 로그에 로드 실패나 존재하지 않는 프록시 그룹 참조 등의 오류가 있는지 확인합니다.
‘프록시 / Proxies’ 페이지에서 프록시 그룹이 표시되는지 확인한 다음, 모드가 규칙 모드인 Rule인지 살펴보세요. 마지막으로 예상되는 연결 경로를 알고 있는 사이트를 열고 연결 기록을 확인합니다.

로컬 파일을 가져올 때는 파일 가져오기를 선택하고 .yaml 또는 .yml 파일을 고른 뒤, 활성화와 검증 단계를 진행하세요. 클라이언트마다 메뉴가 ‘가져오기’, ‘새로 만들기’, ‘추가’ 등으로 다를 수 있습니다. 메뉴를 찾기 어렵다면 사용 설명서에서 기본 절차를 확인하세요.

로컬 비교용 설정 만들기: 구문 문제와 네트워크 문제 분리하기

구조가 단순한 로컬 설정을 준비하면 클라이언트가 YAML을 정상적으로 불러오는지 확인하는 데 도움이 됩니다. 다음 예시는 mihomo용으로, 설정 구조와 프록시 그룹 참조를 설명하기 위한 것입니다. 원격 프록시 노드는 포함하지 않으며 프록시 연결도 제공하지 않습니다.

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

proxies: []

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

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

mixed-port: 7890은 HTTP와 SOCKS 요청을 모두 받는 로컬 프록시 포트를 지정합니다. 예시 값일 뿐이며 모든 클라이언트가 7890을 사용하는 것은 아닙니다.
allow-lan: false는 로컬 네트워크 기기가 이 프록시 포트에 접속하지 못하게 합니다. 우선 현재 기기에서 확인할 때 적합합니다.
수동 선택은 프록시 그룹 이름입니다. 규칙의 마지막 항목이 이 이름과 정확히 일치해야 합니다.
DIRECT는 직접 연결, REJECT는 연결 거부를 뜻합니다. 둘 다 내장된 아웃바운드 옵션이며 원격 노드가 아닙니다.
MATCH,DIRECT는 최종 규칙입니다. 앞선 규칙에 해당하지 않는 연결은 직접 연결됩니다.

파일을 local-baseline.yaml로 저장하고 가져온 다음, 이름을 진단-로컬직결로 지정하세요. 이 설정이 정상적으로 로드되더라도 기본 구조를 받아들였다는 뜻일 뿐, 구독 노드를 사용할 수 있다는 의미는 아닙니다. 클라이언트에서 전역 재정의를 활성화했다면 실제 포트와 모드는 파일 내용과 다를 수도 있습니다.

YAML을 편집할 때는 Tab 대신 공백으로 들여쓰세요. 필드를 자세히 확인하려면 YAML 설명서를 참고하세요. mihomo용 최신 필드를 구형 Clash 커널에 그대로 적용하지 마세요. 알 수 없는 필드는 오류를 일으키거나 무시될 수 있습니다.

여러 설정의 이름 지정과 전환: 용도를 분명히 하고 같은 순서로 확인하기

대부분의 클라이언트는 한 번에 하나의 주 설정만 활성화합니다. Profile이 세 개 있다고 해서 세 구독이 자동으로 합쳐지거나 트래픽이 동시에 분배되는 것은 아닙니다. 여러 출처의 내용을 하나의 설정에 담으려면 보통 Provider나 클라이언트에서 지원하는 병합 기능이 필요합니다.

표시 이름	출처	유지 목적
일상-구독A	원격 구독	평소 사용, 정기 업데이트
예비-구독B	별도의 원격 구독	주 설정에 문제가 생겼을 때 비교 점검
진단-로컬직결	로컬 YAML	설정 로드와 직접 연결 경로 확인
실험-규칙수정	로컬 사본	수정을 테스트하며 일상 설정에 영향 주지 않기

전환할 때마다 네 가지 확인

활성 항목: 편집 창만 연 것이 아니라 선택 표시가 대상 설정으로 실제 이동했는지 확인하세요.
실행 모드: Rule은 규칙에 따라 연결을 분기하고, Global은 전역 정책을 적용하며, Direct는 직접 연결합니다. 인터페이스에 저장된 모드가 파일의 mode 설정을 덮어쓸 수 있습니다.
프록시 그룹 선택: 규칙에서 실제로 참조하는 그룹을 열어 현재 선택 항목을 확인하세요. 새 설정에서 그룹 이름이 바뀌면 기존 선택 기록이 그대로 유지되지 않을 수 있습니다.
새 연결 기록: 요청을 새로 보내 어떤 규칙과 프록시 그룹이 적용되고 최종적으로 어디로 연결되는지 확인하세요. 브라우저에서 이미 열린 장기 연결은 전환 전 경로를 잠시 유지할 수 있습니다.

전환 후 결과가 바로 달라지지 않으면 테스트 페이지를 닫았다가 다시 여세요. 필요하다면 기존 연결 중 해당 연결만 종료하세요. 처음부터 클라이언트를 재설치하고 모든 설정을 지우고 DNS까지 바꾸지는 마세요. 한꺼번에 너무 많이 변경하면 원인을 찾기 어려워집니다.

정기 업데이트와 사용자 규칙: 변경 사항을 어디서 관리하는지 구분하기

업데이트 주기는 관리 정책이며, 짧을수록 좋은 것은 아닙니다. 예를 들어 일반 구독은 우선 24시간 간격으로 새로고침하도록 설정할 수 있습니다. 제공자가 별도 지침을 안내했다면 그 내용을 따르세요. 입력 단위가 분이면 24시간은 1440분, 초이면 86400초입니다. 저장 전에 단위를 확인하세요.

정기 업데이트는 보통 클라이언트가 담당하며, 컴퓨터가 절전 상태이거나 프로그램이 종료되어 있으면 실행되지 않을 수 있습니다. proxy-providers의 interval은 커널 Provider 설정 필드로, 보통 초 단위입니다. 이를 클라이언트의 전체 Profile 업데이트 일정 대신 사용할 수는 없습니다.

계속 유지할 규칙은 별도의 수정 계층에 두기

클라이언트에 ‘재정의’, ‘병합’ 또는 스크립트 처리 기능이 있다면 먼저 관련 설명을 읽고 사용자 지정 내용을 별도 계층에 두세요. 병합 순서는 클라이언트마다 다릅니다.
원본 파일 편집 기능만 있다면 먼저 사본을 내보낸 뒤 수정하고, 이후에도 직접 관리해야 한다는 점을 고려하세요.
규칙을 추가할 때는 순서에 유의하세요. 일반적으로 규칙은 위에서 아래로 검사되므로 새 규칙을 MATCH 뒤에 추가하면 예상대로 동작하지 않을 수 있습니다.
업데이트 후에는 구독 원본 파일만 보지 말고 최종 적용 설정을 확인하세요. 클라이언트가 포트, DNS 또는 TUN 재정의를 추가로 적용했을 수 있습니다.

전환 후 규칙이 꼬일 때: 노드를 무작정 바꾸지 말고 증상별로 점검하기

프록시 그룹이 사라지거나 규칙이 존재하지 않는 이름을 가리킴

먼저 로드 로그를 확인하세요. 예를 들어 규칙은 일상 프록시를 참조하는데 새 설정에는 수동 선택만 정의되어 있다면 참조가 일치하지 않습니다. 철자와 대소문자, 공백을 확인한 뒤 재정의 규칙이 이전 설정의 그룹 이름을 계속 참조하는지도 살펴보세요. 그룹 이름을 바꿨다면 사용자 지정 규칙도 함께 수정해야 합니다.

전환은 성공했지만 일부 앱만 프록시를 사용함

먼저 트래픽이 커널에 전달되고 있는지 확인하세요. 시스템 프록시는 운영체제에서 제공하는 프록시 설정이므로 모든 앱이 따르는 것은 아닙니다. TUN 모드는 가상 네트워크 인터페이스로 트래픽을 처리하며 권한, 라우팅, DNS 설정도 올바르게 구성해야 합니다. Profile을 전환한다고 이런 연결 경로 문제가 자동으로 해결되지는 않습니다.

앱이 여전히 127.0.0.1:7890을 가리키는데 실행 중인 포트가 7897로 바뀌었다면, 앱이 이전 포트에 연결하거나 오류를 낼 수 있습니다. 두 숫자는 점검을 위한 예시이므로 클라이언트에 표시된 실제 수신 포트를 기준으로 하세요. 전환할 때 시스템 프록시 설정도 함께 갱신되는지 별도로 확인해야 합니다.

페이지는 열리지만 예상과 다른 경로로 연결됨

먼저 연결 기록에 도메인이 표시되는지 확인하고, 어떤 규칙이 적용됐는지 살펴보세요. 앱 자체 DNS, 암호화 DNS, IP 직접 연결, 기존 연결 재사용 등이 관찰 결과에 영향을 줄 수 있습니다. 한 웹사이트에 표시된 접속 위치만으로 전체 설정이 적용됐다고 판단하지 마세요. 도메인을 명확히 알고 있는 사이트에서 새 연결을 만들고 해당 로그와 함께 확인하세요.

새로고침 후 사용할 수 없지만 이전 설정은 정상임

오류 내용을 보존하고 최근에 정상 작동한 사본으로 복구한 뒤 노드, 그룹 이름, 규칙이 어떻게 바뀌었는지 비교하세요. 구독 응답에 문제가 있다면 제공자에게 형식과 유효 기간을 먼저 문의해야 합니다. 업데이트 버튼을 연달아 눌러도 같은 요청만 반복될 뿐, 원격 콘텐츠 오류는 해결되지 않습니다. 연결 경로에 관한 다른 문제는 자주 묻는 질문을 참고해 하나씩 점검하세요.

백업과 롤백: 검증된 설정을 최소 한 개 보관하기

백업에는 설정 내용뿐 아니라 사용 상태도 포함해야 합니다. 구독 URL만 저장하면 당시의 규칙을 복원할 수 없고, YAML만 저장하면 클라이언트의 모드, TUN 스위치, 재정의 설정이 빠질 수 있습니다.

큰 변경을 하기 전에 현재 정상 작동하는 설정을 내보내세요. 파일 이름은 날짜로 구분하기 쉽도록 daily-before-edit-2026-08-03.yaml처럼 지정할 수 있습니다.
커널 종류, 실제 수신 포트, 모드, 프록시 그룹 선택, 현재 활성화된 재정의 항목을 기록하세요. 스크린샷을 찍을 때는 구독 URL과 노드 인증 정보를 가리세요.
변경 사항은 새 항목에서 테스트하세요. 정상적으로 로드되고 규칙도 예상대로 적용되는지 확인한 다음 일상 설정을 교체할지 결정하세요.
롤백할 때는 백업 항목을 선택하고 해당 클라이언트 설정도 복원한 뒤 새 연결로 확인하세요. ‘파일 가져오기 성공’을 복구 완료로 여기지 마세요.

일상적인 관리는 간단하게 유지할 수 있습니다. 일상용 구독 하나, 예비 설정 하나, 로컬 진단 설정 하나를 준비하세요. 출처를 구분하고 이름을 일관되게 정한 뒤 전환할 때마다 같은 순서로 확인하면 됩니다. 문제가 생겼을 때 설정 내용, 업데이트 과정, 시스템 프록시나 TUN 같은 트래픽 경로 중 어디에서 원인이 발생했는지 파악하기 쉽습니다.