Clash 설정 파일(Profile)이란? 기본 개념과 다중 설정 관리법

Profile이란: 지시사항이 담긴 처방전 한 장

가장 많이 묻는 질문부터 답하자면, Clash에서 말하는 「설정」(Profile)이란 정확히 무엇일까요? 바로 YAML 형식의 텍스트 파일입니다. Clash가 실행된 후의 모든 동작—어떤 포트로 연결을 받을지, 트래픽을 어떤 순서로 분류할지, 최종적으로 어떤 노드로 내보낼지—전부 이 파일에 따라 실행됩니다. Clash Verge, Clash for Windows를 비롯한 각종 mihomo 기반 GUI 클라이언트에서 「설정」 탭에 나열된 항목 하나하나가 독립된 Profile이며, 클릭 한 번으로 여러 설정 사이를 전환할 수 있습니다.

어떤 설정을 열어봐도 구조는 대체로 비슷합니다. 공통 설정 외에 핵심 항목 세 가지로 구성됩니다.

mixed-port: 7890        # 로컬 프록시 포트
allow-lan: false        # LAN 기기 접속 허용 여부
mode: rule              # 트래픽 분배 모드: rule / global / direct
log-level: info

proxies:                # 노드 목록
  - name: "노드A"
    type: ss
    server: example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"

proxy-groups:           # 프록시 그룹: 노드를 묶어 규칙에서 참조
  - name: 자동 선택
    type: url-test
    proxies: ["노드A", "노드B"]
    url: http://www.gstatic.com/generate_204
    interval: 300

rules:                  # 분배 규칙: 위에서부터 순서대로 매칭
  - DOMAIN-SUFFIX,google.com,자동 선택
  - GEOIP,CN,DIRECT
  - MATCH,자동 선택

• proxies: 노드 목록입니다. 각 노드마다 프로토콜 종류, 서버, 포트, 인증 정보가 기재되며, 설정 전체의 원재료 역할을 합니다.
• proxy-groups: 프록시 그룹입니다. 노드를 수동 선택, 자동 속도 테스트(url-test), 장애 조치(fallback) 등의 방식으로 묶으며, 규칙은 노드를 직접 지정하지 않고 그룹만 참조합니다.
• rules: 분배 규칙입니다. 위에서부터 순서대로 매칭되며, 일치하는 규칙이 지정한 경로로 트래픽이 전달됩니다. 마지막의 MATCH가 나머지 트래픽을 처리합니다.
• 공통 설정: mixed-port(로컬 프록시 포트), allow-lan(LAN 기기 접속 허용 여부), mode(rule / global / direct 세 가지 모드), log-level 등이 있으며, mihomo 코어 설정에는 dns, tun 같은 항목도 추가됩니다.

한 문장으로 정리하면: proxies는 약재, proxy-groups는 약재를 담는 서랍, rules는 조제 순서입니다. 셋이 모두 갖춰져야 처방이 완성됩니다. rules가 없으면 모든 트래픽이 한 그룹으로만 흐르고, proxies가 없으면 조제할 약재 자체가 없는 것과 같습니다.

구독 링크와 로컬 파일: Profile의 두 가지 출처

출처로 나누면 Profile은 딱 두 종류입니다. 구독 링크로 생성된 것과 로컬 파일로 가져온 것입니다. 클라이언트의 설정 목록에서는 겉모습이 똑같아 보이지만 동작 방식은 전혀 다릅니다. 이 차이를 구분하지 못하는 것이 이후 「수정 내용이 사라졌다」는 모든 문제의 근본 원인입니다.

구독 링크의 본질은 그렇게 특별하지 않습니다. 서비스 제공업체가 특정 URL에 YAML 파일을 호스팅해두고, 클라이언트가 해당 주소로 접속해 다운로드한 뒤 설정 디렉터리에 로컬 복사본으로 저장하는 방식입니다. 즉 구독 설정도 결국 하드디스크에 저장된 .yaml 파일이며, 다만 주기적으로 「최신 버전을 다시 가져오는」 기능이 붙어 있을 뿐입니다. 이 점이 다음 절에서 다룰 증상으로 이어집니다.

「수정하면 사라지는」 이유: 구독 업데이트는 전체 덮어쓰기

증상: 구독 설정에 규칙을 몇 개 추가하거나 포트를 바꾸면 당시에는 정상 작동합니다. 그런데 며칠 지나 다시 보면 수정 내용이 모두 원래대로 돌아가 있고, 마치 아무것도 손대지 않은 것처럼 보입니다.

원인: 구독을 업데이트하는 동작은 원래 링크에서 원격 파일을 다시 다운로드해 로컬 복사본 전체를 교체하는 것과 같습니다. 클라이언트는 차이점을 비교하지 않으며, 수동으로 수정한 내용을 따로 보존해주지도 않습니다. 자동 업데이트 주기(흔히 24시간 또는 48시간)를 설정해두면 시간이 되는 즉시 아무런 알림 없이 덮어씁니다. 이는 오류가 아니라 구독 기능 본래의 동작 방식입니다. 사용자의 설정을 서비스 제공업체 측 최신 버전과 항상 일치시키는 것이 구독의 역할입니다.

사용자 수정 내용을 지키는 세 가지 방법

수정 범위가 작은 것부터 큰 순서로 정리하면 다음과 같습니다.

1. 병합(Merge) / 오버라이드 기능(우선 추천). Clash Verge의 「병합(Merge)」 기능이나 Clash for Windows의 Mixin은 원리가 같습니다. 구독 원본은 그대로 두고, 별도의 작은 YAML 패치 파일을 작성해두면 클라이언트가 설정을 불러올 때 패치를 위에 덮어씌웁니다. 구독을 업데이트해도 원본만 바뀌고 패치는 그대로 적용됩니다. dns 항목 수정, 규칙 몇 개 추가·삭제, 포트 변경 같은 소규모 작업에 적합합니다. 주의할 점 두 가지: 패치의 필드 이름을 잘못 쓰면 아무 오류 메시지 없이 조용히 무시되므로, 수정 후에는 반드시 설정을 다시 불러오고 로그를 확인하세요. 패치와 원본이 충돌할 때의 우선순위는 각 클라이언트의 공식 문서를 참고하세요.
2. 로컬 설정으로 복사한 뒤 수정. 구독으로 다운로드한 파일을 별도로 저장해 로컬 파일 형식으로 가져오면, 이후로는 자유롭게 편집할 수 있고 구독 업데이트로 인한 덮어쓰기와도 무관해집니다. 다만 구독과의 연결이 끊어지므로 노드 추가·삭제, 규칙 변경을 모두 수동으로 동기화해야 합니다. 수정량이 많고 구독 자체 업데이트가 자주 일어나지 않는 경우에 적합합니다.
3. proxy-providers / rule-providers로 분리 참조(mihomo 코어). 직접 로컬 메인 설정을 만들어, 노드 목록은 proxy-providers로 구독 주소를 지정하고 규칙 세트는 rule-providers로 외부 링크를 참조하게 합니다. 메인 설정은 전적으로 사용자가 관리하며, 구독은 참조되는 재료 공급원 역할만 하므로 양쪽의 업데이트가 서로 간섭하지 않습니다.

proxy-providers:
  내 구독:
    type: http
    url: "https://example.com/subscribe.yaml"
    interval: 86400
    path: ./providers/subscribe.yaml
    health-check:
      enable: true
      url: http://www.gstatic.com/generate_204
      interval: 300

세 번째 방법은 진입 장벽이 가장 높지만 가장 근본적인 해결책입니다. 메인 설정에는 자신만의 프록시 그룹과 규칙 구조만 작성하고, 노드는 구독에 따라 자동으로 갱신되므로 이후로는 「덮어쓰기」 문제 자체가 사라집니다.

다중 설정 공존: 이름 관리, 전환, 백업

한 사람이 두세 개의 설정을 동시에 보유하는 것은 드문 일이 아닙니다. 서비스 제공업체별로 하나씩, 주 라인과 보조 라인 각각 하나씩, 업무용과 개인용을 분리하는 식입니다. 다중 설정을 관리할 때는 다음 사항을 챙기세요.

• 가져오는 즉시 이름 변경. 기본 이름은 대개 의미를 알 수 없는 문자열이므로, 「출처 + 용도」 형식으로 바꿔두면 몇 달이 지나도 알아볼 수 있습니다.
• 포트 통일. 각 설정의 mixed-port를 동일하게(예: 모두 7890) 맞추세요. 그렇지 않으면 설정을 전환했을 때 시스템 프록시나 다른 프로그램에 고정된 포트와 맞지 않아 「전환 후 인터넷이 안 된다」는 증상이 나타납니다.
• 업데이트 주기는 너무 짧게 잡지 말 것. 구독 설정은 24시간 간격이면 충분합니다. 너무 자주 가져오면 얻는 이점 없이 수정 내용이 덮어써질 빈도만 늘어납니다.
• 전환 후 세 가지 확인. 현재 모드가 여전히 rule인지, 시스템 프록시가 정상 연결됐는지, 해외 사이트 접속으로 링크가 정상인지 확인하세요. 설정을 전환하면 코어가 재시작되므로 진행 중인 연결이 잠시 끊기는 것은 정상입니다.
• 백업은 두 가지를 함께. 설정 디렉터리 전체를 복사해 보관하고, 구독 링크 자체도 따로 기록해두세요. 링크만 있으면 언제든 설정을 재구성할 수 있으니, 이것이 가장 확실한 대비책입니다.

자주 발생하는 증상 빠른 점검

• 구독 업데이트 후 사용자 규칙이 사라짐 → 병합 오버라이드나 로컬 복사본 방식으로 전환하세요. 자세한 방법은 네 번째 절을 참고하세요.
• 구독을 가져올 때 파싱 실패 메시지가 나타남 → 링크가 반환한 내용이 YAML 형식이 아닐 가능성이 큽니다. 일부 구독 주소는 클라이언트 식별 정보를 확인해야 Clash 형식으로 반환하거나, 사전에 구독 변환이 필요한 경우가 있습니다. 파일 인코딩 오류도 이런 오류를 일으킬 수 있습니다.
• 설정 전환 시 포트가 이미 사용 중이라는 메시지가 나타남 → 두 설정의 mixed-port가 충돌하거나 이전 코어 프로세스가 완전히 종료되지 않은 경우입니다. 남아 있는 프로세스를 종료한 뒤 다시 전환하세요.
• 설정을 수정했는데 적용되지 않음 → 수정 후에는 설정을 다시 불러오거나 코어를 재시작해야 합니다. 일부 클라이언트는 저장 즉시 자동으로 다시 불러오지만, 일부는 수동으로 클릭해야 하니 이 단계를 빠뜨리지 마세요.

Profile의 기본 개념은 여기까지입니다. 하나의 YAML 파일, 두 가지 출처, 하나의 덮어쓰기 원칙, 그리고 수정 내용을 지키는 세 가지 방법을 정리했습니다. 이제 실제로 적용해보시면 됩니다. 클라이언트 자체를 설치하고 처음 구독 링크를 가져오는 방법은 아래 안내를 참고하세요.