Clash Profile이란? 여러 설정 파일 관리 및 전환 방법

Profile과 config.yaml의 관계

Profile은 일반적으로 Clash GUI 클라이언트에서 선택해 사용하는 설정 프로필을 뜻합니다. 로컬 YAML 파일을 불러오거나 원격 구독 주소와 연결할 수 있습니다. 설정 내용 외에도 클라이언트가 이름, 출처, 업데이트 시각, 오버라이드 설정을 저장하기도 합니다. 이러한 관리 정보는 클라이언트에 보관되며, 커널이 읽는 YAML 파일에는 포함되지 않을 수 있습니다.

config.yaml은 흔히 사용하는 커널 설정 파일 이름입니다. Clash Meta 프로젝트에서 발전한 커널인 mihomo는 수신 포트, 노드, 프록시 그룹, DNS, 라우팅 규칙 등이 포함된 설정을 읽을 수 있습니다. 파일 이름을 반드시 config.yaml로 지정할 필요는 없습니다. 명령줄에서는 -f로 다른 파일을 지정할 수 있고, GUI 클라이언트가 자체 런타임 파일을 생성하기도 합니다.

• Profile 목록: 용도별로 선택할 수 있도록 여러 설정 후보를 저장합니다.
• 현재 활성화된 Profile: 클라이언트가 현재 설정을 생성하거나 불러올 때 사용합니다.
• 런타임 설정: 커널이 실제로 사용하는 설정입니다. 전역 설정, 오버라이드, 스크립트 처리 내용이 적용되어 있을 수 있습니다.

따라서 문제를 진단할 때는 원본 구독, 클라이언트에서 편집한 결과, 커널의 현재 설정을 구분해야 합니다. 디스크에 있는 config.yaml만 열어서는 연결 로그에 실제 적용 중인 모든 규칙을 확인할 수 없을 수도 있습니다.

로컬 설정과 원격 구독, 무엇을 선택할까

로컬 설정에도 proxy-providers나 rule-providers를 넣어 노드와 규칙을 원격에서 가져올 수 있습니다. 여기서 ‘로컬’은 Profile을 불러온 경로를 뜻할 뿐, 모든 리소스가 오프라인으로 저장되어 있다는 의미는 아닙니다. 백업할 때 provider 캐시와 종속 파일을 빠뜨리면 오프라인 환경에서 복구하지 못할 수도 있습니다.

구독 URL과 설정 형식은 다릅니다

같은 가져오기 입력란에 URL을 넣더라도 해당 URL이 반환하는 내용은 다를 수 있습니다. 완전한 Clash YAML에는 proxies, proxy-groups, rules가 포함될 수 있습니다. Base64로 인코딩된 노드 목록에는 보통 노드 정보만 들어 있으므로 완전한 규칙 설정으로 바로 사용할 수 없습니다. provider 전용으로 제공되는 YAML proxies 목록도 완전한 Profile과는 다릅니다.

가져오기에 실패하면 먼저 클라이언트의 오류 내용을 확인해 설정 파일 대신 로그인 페이지, 만료 안내 또는 HTML 오류 페이지가 반환된 것은 아닌지 살펴보세요. 서버에서 형식을 선택할 수 있다면 현재 커널과 호환되는 Clash 또는 mihomo 설정을 선택하세요. 구독 주소에는 접근 토큰이 포함되는 경우가 많으므로 공개 변환 사이트, 스크린샷, 문의 글에 노출하지 마세요.

여러 설정 파일의 이름 지정 및 분류 방법

이름은 용도를 먼저 적고, 출처를 다음에 표시한 뒤, 테스트용 복사본인지 구분하세요. ‘설정 1’, ‘새 구독’처럼 짓거나 ‘최종본’을 계속 덧붙이면 어떤 설정을 안전하게 업데이트할 수 있는지 판단하기 어렵습니다. 아래 이름은 그대로 활용할 수 있습니다.

• 일상-기본 구독: 서버 업데이트를 유지하며 평소에 사용합니다.
• 예비-별도 구독: 다른 출처를 사용하며 장애가 발생하면 직접 전환합니다.
• 업무-로컬 규칙: 업무 도메인과 사설 네트워크 주소를 처리합니다.
• 테스트-DNS-2026-08-18: DNS 변경 사항만 확인하며 일상 설정을 덮어쓰지 않습니다.

날짜는 스냅샷과 테스트용 복사본에 넣고, 장기간 사용할 구독 이름은 일정하게 유지하세요. 각 설정의 메모에는 출처 유형, 호환 커널, 의존하는 오버라이드 이름을 기록하는 것이 좋습니다. 예를 들어 ‘원격 YAML, mihomo, 업무 도메인 규칙 적용’이라고 적으면 서비스 업체 약칭만 기록하는 것보다 다른 환경으로 옮길 때 유용합니다.

예비 설정은 미리 확인하세요

이름이 다른 두 Profile이 실제로는 같은 구독 주소를 가리킬 수 있습니다. 이런 복사본은 설정 변경을 시험하는 데는 쓸 수 있지만, 독립적인 회선 예비용은 아닙니다. 예비 설정이 정상적으로 업데이트되는지, 프록시 그룹에서 노드를 선택할 수 있는지, 필요한 사이트에 접속되는지 미리 확인한 다음 일상 설정으로 돌아가세요. 주 회선이 끊긴 뒤 처음 가져오면 구독 다운로드와 노드 연결 문제가 동시에 발생할 수 있습니다.

Profile 전환 방법 및 확인 순서

클라이언트마다 ‘설정’, ‘구독’, ‘Profiles’ 등 진입 메뉴가 다르고 버튼 이름도 버전에 따라 바뀔 수 있습니다. 설정 목록에서 원하는 항목을 찾은 다음 ‘편집’, ‘업데이트’, ‘활성화’를 구분하세요. 편집은 내용을 바꾸고, 업데이트는 출처에서 새 내용을 가져오며, 활성화는 현재 설정을 전환합니다. 업데이트 후 자동으로 다시 불러오는 클라이언트도 있고, 별도로 확인해야 하는 클라이언트도 있습니다.

1. 현재 상태를 기록합니다. 현재 Profile, 규칙 모드, 프록시 그룹 선택, 시스템 프록시 설정을 기록하세요. 필요한 경우 구독 주소가 보이지 않도록 주의해 화면을 캡처합니다.
2. 대상 항목을 업데이트합니다. 원격 Profile은 먼저 새로고침하고 업데이트 시각과 오류 안내를 확인하세요. 로컬 설정은 종속 파일 경로를 확인합니다.
3. 대상 설정을 활성화합니다. 로딩이 끝날 때까지 기다린 뒤 로그에 YAML 파싱 오류, 존재하지 않는 정책, 리소스 다운로드 실패가 있는지 확인합니다.
4. 프록시 그룹을 다시 선택합니다. 새 설정에서는 그룹 이름이 달라질 수 있으므로 이전에 선택한 노드가 그대로 유지된다고 가정하면 안 됩니다.
5. 새 연결을 만듭니다. 테스트 페이지를 다시 열고 연결 세부 정보에서 규칙, 정책 경로, 대상 주소를 확인합니다.

예를 들어 이전 설정이 mixed-port: 7890을 사용하고 새 설정은 mixed-port: 7897로 바뀌었는데 터미널의 프록시 주소가 계속 127.0.0.1:7890을 가리키면 연결에 실패할 수 있습니다. GUI 클라이언트가 Profile의 포트를 전역 포트 설정으로 덮어쓸 수도 있으므로 파일 두 개만 비교하지 말고 실제 수신 포트를 확인하세요.

Linux에서는 다음 명령으로 예시 포트가 수신 대기 중인지 확인할 수 있습니다. 다른 포트를 사용한다면 실제 값에 맞게 바꾸세요.

ss -lntp 'sport = :7890'
ss -lntp 'sport = :7897'

이미 다운로드 중인 파일, 재생 중인 영상, 장시간 연결은 전환 전 연결을 계속 사용할 수 있습니다. 확인할 때는 새 연결을 우선 사용하세요. 필요하면 클라이언트의 연결 페이지에서 관련 연결을 닫고 다시 시도해 기존 연결의 출구를 새 설정이 적용되지 않은 것으로 오해하지 않도록 합니다.

사용자 지정 규칙, 어디에 두어야 관리하기 쉬울까

원격 구독은 업데이트 가능한 원본으로 유지하고, 장기간 사용할 변경 사항은 클라이언트에서 지원하는 오버라이드, 병합 또는 스크립트 기능에 넣으세요. 클라이언트마다 필드 병합 방식이 다릅니다. 목록 전체를 교체하는 경우도 있고, 규칙을 앞이나 뒤에 추가할 수 있는 경우도 있습니다. 저장하기 전에 생성된 설정을 확인해 수정 내용이 실제 런타임 설정에 반영됐는지 검토하세요.

규칙 순서와 프록시 그룹 이름을 함께 확인하세요

다음은 규칙 순서를 보여 주는 예시일 뿐, 완전한 설정은 아닙니다. 내부 예시 도메인과 사설 네트워크 대역은 직접 연결하고 나머지 트래픽은 뒤에 이어지는 규칙으로 처리합니다.

rules:
  - DOMAIN-SUFFIX,office.example,DIRECT
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
  - MATCH,DIRECT

office.example은 예시용 예약 도메인입니다. 실제 업무 환경에서 사용하는 도메인으로 간주해서는 안 됩니다. 마지막의 MATCH,DIRECT는 예시를 완결된 형태로 보여 주기 위한 것으로, 그대로 복사하면 나머지 트래픽이 모두 직접 연결됩니다. 실제 설정에는 필요한 후속 규칙을 유지하고 이미 정의된 기본 정책을 사용하세요.

규칙은 위에서 아래 순서로 적용됩니다. 사용자 지정 도메인 규칙을 MATCH 뒤에 추가하면 실행되지 않습니다. 규칙에서 업무 출구라는 프록시 그룹을 지정했다면 전환할 설정에도 같은 이름의 그룹이 있어야 합니다. 그룹 이름에 의존하지 않으려면 DIRECT만 지정할 수 있지만, 직접 연결이 요구 사항에 맞는지는 업무 환경에 따라 판단해야 합니다.

한 번에 한 종류의 설정만 변경하세요

먼저 규칙을 확인하고 DNS를 변경한 뒤 마지막으로 TUN을 점검하세요. 구독 교체, DNS 변경, 포트 수정, TUN 활성화를 한꺼번에 하면 문제가 생겼을 때 원인을 찾기 어렵습니다. 전역 오버라이드는 모든 Profile에 영향을 줄 수도 있습니다. 테스트 설정에만 새 DNS를 적용하려면 오버라이드의 적용 범위를 먼저 확인하세요.

백업, 설정 테스트 및 롤백

완전한 백업에는 원본 설정, 클라이언트 관리 데이터, 사용자 지정 오버라이드가 최소한 포함되어야 합니다. 런타임 config.yaml만 복사하면 구독 URL, 자동 업데이트 시각, 스크립트, 프록시 그룹 선택 기록이 빠질 수 있습니다. 클라이언트 목록만 내보내면 provider의 실제 콘텐츠가 저장되지 않을 수도 있습니다.

1. 클라이언트에서 지원하는 내보내기 또는 백업 기능으로 복사본을 만들고 클라이언트 버전과 커널 버전을 기록하세요.
2. 직접 관리하는 규칙, 오버라이드 스크립트, provider 파일, 필요한 인증서 종속 항목도 함께 보관하세요.
3. 변경 전후 스냅샷에는 daily-2026-08-18.yaml처럼 날짜를 붙여 유일하게 사용할 수 있는 복사본을 덮어쓰지 않도록 하세요.
4. 노드 비밀번호, 구독 토큰, 제어 인터페이스 키가 포함된 백업은 접근이 제한된 디렉터리에 보관하고 공유하기 전에 민감한 정보를 가리세요.

mihomo로 설정 후보 파일 테스트하기

명령줄을 사용한다면 먼저 커널 버전을 확인한 다음 별도 디렉터리에서 후보 파일을 테스트할 수 있습니다. 아래 예시는 현재 디렉터리에 candidate.yaml이 있고 mihomo가 명령 검색 경로에 추가되어 있다고 가정합니다.

mihomo -v
mkdir -p ./profile-check
mihomo -t -d ./profile-check -f ./candidate.yaml

-t는 설정 테스트, -d는 작업 디렉터리 지정, -f는 설정 파일 지정에 사용합니다. 상대 경로와 외부 리소스는 실제 디렉터리에 맞게 준비해야 하며, 규칙 세트 등의 리소스는 다운로드가 필요할 수 있습니다. 테스트 통과는 커널이 이 설정을 받아들였다는 뜻일 뿐, 노드 연결이나 DNS가 정상이고 시스템 프록시가 적용됐다는 뜻은 아닙니다.

롤백하려면 먼저 이전에 정상 작동하던 Profile을 복원하고 연결된 오버라이드도 복원한 뒤 다시 불러와 새 연결을 테스트하세요. 명령줄을 사용하는 경우 디스크의 파일을 교체한 다음 기존 관리 방법으로 설정을 다시 불러오거나 해당 서비스를 재시작해야 합니다. 파일을 덮어쓰기만 해서는 커널이 새 설정을 읽지 않습니다.

Profile 관리 자주 묻는 질문

일상적인 관리는 원본 출처 유지, 오버라이드를 통한 장기 규칙 관리, 전환 후 새 연결 확인, 중요한 변경 전 롤백 가능한 스냅샷 저장 순서로 진행하면 됩니다. 설정 수를 늘리는 것보다 출처와 적용 범위를 명확히 하고 복구 절차를 반복할 수 있게 만드는 것이 중요합니다.