Profile, 구독 링크, config.yaml을 먼저 구분하기
핵심부터 말하면, Profile은 클라이언트가 하나의 프록시 설정을 관리하는 논리적 단위입니다. 구독 링크는 해당 설정의 원격 출처이고, YAML 파일은 클라이언트가 다운로드하거나 가져온 뒤 로컬에 저장하는 실제 내용입니다. 서로 연결되어 있지만 같은 것은 아닙니다.
Clash Verge Rev, Clash Nyanpasu 같은 그래픽 클라이언트에서는 Profile을 흔히 ‘구독’, ‘설정’ 또는 ‘설정 파일’로 표시합니다. 하나의 Profile에는 보통 이름, 출처 주소, 로컬 파일 경로, 업데이트 시간, 현재 활성화 상태가 포함됩니다. 사용자가 항목을 클릭하면 클라이언트가 해당 YAML을 읽고 문법을 확인한 다음, 처리된 설정을 Mihomo 코어에 전달해 실행합니다.
| 대상 | 주요 역할 | 일반적인 형태 | 업데이트 방식 |
|---|---|---|---|
| Profile | 클라이언트에서 설정을 구성하고 선택하며 관리 | 설정 목록의 항목 하나 | 전환, 이름 변경 또는 다시 가져오기 |
| 구독 링크 | 원격 설정 내용 제공 | HTTPS로 시작하는 URL | 클라이언트가 주소로 요청 |
| YAML 파일 | 포트, 노드, 프록시 그룹, 규칙 저장 | config.yaml 또는 다른 이름 | 원격 덮어쓰기 또는 로컬 편집 |
| 실행 시 적용되는 설정 | Mihomo 코어가 실제로 실행할 설정 | 클라이언트가 병합하고 덮어쓴 결과 | Profile 전환 또는 코어 다시 불러오기 |
config.yaml은 자주 쓰이는 파일 이름일 뿐입니다
config.yaml은 Clash 생태계에서 흔히 사용하는 기본 이름일 뿐, 모든 Profile이 반드시 이 이름을 써야 하는 것은 아닙니다. 그래픽 클라이언트는 이름 충돌을 피하기 위해 파일을 7f2c8a.yaml 같은 임의 식별자로 저장할 수 있으며, 구독 이름별로 별도 폴더를 만들기도 합니다. 이 경우 목록에는 ‘업무용 회선’으로 표시되지만 디스크의 파일 이름은 전혀 다를 수 있습니다.
실행 가능한 기본 YAML에는 보통 수신 포트, 프록시 노드, 프록시 그룹, 규칙이 포함됩니다. 아래 구조는 실제 노드 인증 정보 없이 Profile 각 부분의 관계만 보여 줍니다:
mixed-port: 7890
mode: rule
log-level: info
proxies:
- name: "예시 노드"
type: socks5
server: 127.0.0.1
port: 1080
proxy-groups:
- name: "노드 선택"
type: select
proxies:
- "예시 노드"
- DIRECT
rules:
- DOMAIN-SUFFIX,example.com,노드 선택
- MATCH,DIRECT여러 Profile 만들기: 이름을 정한 뒤 가져오기
여러 설정을 함께 사용할 때 가장 실용적인 관리 방법은 ‘설정 1’, ‘새 구독’ 같은 기본 이름을 그대로 두지 않고 가져온 날 용도를 명확히 적는 것입니다. 이름에는 최소한 세 가지 정보가 드러나야 합니다. 어떤 상황에서 쓰는지, 어느 회선 묶음에서 가져왔는지, 자동 업데이트를 허용하는지입니다.
‘용도—출처—업데이트 방식’으로 이름 지정하기
- 일상—주 구독—자동 업데이트: 평소에 사용하며 클라이언트가 정기적으로 가져오도록 허용합니다.
- 업무—내부 규칙—수동 업데이트: 회사 도메인 분류 규칙이 포함되어 있으므로 업데이트 전에 규칙 변경 사항을 확인합니다.
- 모바일 네트워크—저트래픽: 프록시 그룹에서 안정성이 높고 데이터 사용량이 적은 노드를 우선 선택합니다.
- 테스트—로컬 YAML—덮어쓰기 금지: 규칙, DNS 또는 TUN 매개변수를 디버깅할 때 사용합니다.
- 복구용—2026-08-27: 정상 작동이 확인된 정적 사본을 보관합니다.
Clash Verge Rev 2.x의 일반적인 화면을 예로 들면, ‘구독’ → ‘새로 만들기’로 이동해 구독 URL과 이름을 입력하고 저장한 다음 다운로드 또는 새로 고침 버튼을 누릅니다. 로컬 파일을 가져올 때는 ‘구독’ → ‘새로 만들기’ → ‘로컬 파일’을 선택하고 확장자가 .yaml 또는 .yml인 파일을 지정합니다. 버전에 따라 버튼 이름이 ‘가져오기’, ‘새 설정’ 또는 ‘구독 추가’로 표시될 수 있지만 핵심 절차는 같습니다.
- 현재 사용 중인 Profile 이름을 먼저 기록합니다.
- 원격 구독을 새로 만들거나 로컬 YAML을 가져옵니다.
- 기본 이름을 알아보기 쉬운 용도별 이름으로 바꿉니다.
- 수동 업데이트를 한 번 실행해 업데이트 시간이 변경되는지 확인합니다.
- 설정 세부 정보에서 노드 수, 프록시 그룹, 규칙이 모두 있는지 확인합니다.
- 마지막으로 새 Profile로 전환해 가져오기에 실패해도 현재 연결이 끊기지 않도록 합니다.
Profile 전환: 선택 상태만 보지 말고 실제 적용된 설정 확인하기
Profile을 클릭하면 클라이언트는 보통 YAML 파싱, 덮어쓰기 적용, 설정 전달, 프록시 그룹 상태 새로 고침의 네 가지 작업을 수행합니다. 목록에 선택 표시가 나타났다는 것은 전환을 요청했다는 뜻일 뿐입니다. 실제 적용 여부를 판단하려면 코어 상태, 현재 프록시 그룹, 연결 기록을 함께 확인해야 합니다.
전환 후 확인할 네 가지 항목
- 코어 상태 확인: ‘설정’ → ‘코어 설정’ 또는 ‘시스템 설정’ → ‘코어’로 이동해 Mihomo 상태가 실행 중인지 확인합니다.
- 포트 확인: 현재 Profile의
mixed-port가 시스템 프록시 포트와 일치하는지 확인합니다. 흔히7890을 사용하지만 실제 값은 현재 설정을 기준으로 해야 합니다. - 프록시 그룹 확인: ‘프록시’ 페이지에서 ‘노드 선택’, ‘자동 선택’ 등의 그룹이 새 설정에서 가져온 것인지, 이전 Profile의 이름이 아닌지 확인합니다.
- 연결 확인: ‘연결’ 또는 ‘로그’를 열고 테스트 페이지에 접속해 새 연결이 어떤 규칙과 프록시 그룹에 매칭되었는지 확인합니다.
두 Profile이 모두 mixed-port: 7890을 사용한다면 수신 주소와 포트가 그대로이므로 보통 시스템 프록시를 바꿀 필요가 없습니다. 새 설정이 mixed-port: 7897로 변경되었다면 시스템 프록시도 127.0.0.1:7897을 가리키도록 맞춰야 합니다. YAML만 수정하고 기존 시스템 프록시 포트를 유지하면 브라우저가 프록시에 연결되지 않을 수 있습니다.
TUN 모드 전환은 한 단계 더 확인하기
TUN 모드는 가상 네트워크 인터페이스로 트래픽을 가로채므로 일반 시스템 프록시보다 적용 범위가 넓습니다. Profile을 전환한 뒤 tun, DNS, 라우팅 제외 항목 또는 네트워크 스택을 변경했다면 클라이언트에서 TUN을 다시 시작해야 할 수 있습니다. 일반적인 경로는 ‘설정’ → ‘시스템 설정’ → ‘TUN 모드’입니다. 먼저 끄고 2~3초 기다린 다음 다시 켜세요.
TUN을 활성화한 뒤 로그에 인터페이스 생성, 라우팅 등록, DNS 수신 관련 정보가 나타나는지 확인할 수 있습니다. 설정에 dns.listen: 0.0.0.0:1053이 있다면 1053 포트를 다른 실행 중인 프록시 프로그램이 사용하고 있지 않은지도 확인해야 합니다. 여러 클라이언트에서 동시에 TUN을 켜면 기본 경로가 반복해서 변경될 수 있으므로, 전환을 테스트할 때는 코어 하나만 실행하세요.
Profile 업데이트: 원격 새로 고침, 덮어쓰기, 실행 중 설정 다시 불러오기 구분하기
‘구독 업데이트’는 보통 원격 YAML을 다시 다운로드하는 작업입니다. ‘설정 다시 불러오기’는 코어가 로컬 내용을 다시 읽도록 합니다. 일부 클라이언트는 두 작업을 연속으로 실행하지만, 일부는 사용자가 Profile을 한 번 직접 전환해야 합니다. 업데이트 후 노드 수가 변하지 않았다고 해서 반드시 실패한 것은 아닙니다. 서버에서 노드 매개변수나 규칙 내용만 변경했을 수도 있습니다.
업데이트 시간과 로그로 새로 고침 결과 판단하기
업데이트하기 전에 2026-08-27 09:30처럼 Profile에 표시된 시간을 기록해 두세요. 새로 고침 후 시간이 바뀌었는지 확인하고 로그에서 HTTP 상태도 살펴봅니다. 성공적인 요청은 보통 200입니다. 401 또는 403은 구독 권한이나 토큰 만료와 관련된 경우가 많고, 404는 원격 경로가 존재하지 않는다는 뜻입니다. 연결 시간이 초과되면 현재 네트워크와 직접 연결 규칙을 확인해야 합니다.
| 현상 | 우선 확인할 항목 | 해결 방법 |
|---|---|---|
| 업데이트 시간은 바뀌었지만 노드는 이전 이름 그대로임 | 실행 중인 설정을 다시 불러왔는지 확인 | 해당 Profile을 다시 선택하고 필요하면 코어를 재시작 |
| 업데이트 후 사용자 지정 규칙이 사라짐 | 구독 캐시를 직접 편집했는지 확인 | 복구용 사본에서 되돌린 뒤 덮어쓰기 기능 사용 |
| 업데이트 중 YAML 파싱 오류가 표시됨 | 오류가 표시된 줄 주변의 들여쓰기 | 원본 파일을 복원하고 공백으로 들여쓰기 통일 |
| 새 노드는 있지만 프록시 그룹에 표시되지 않음 | 프록시 그룹의 proxies 또는 provider 참조 | 노드가 해당 그룹에 추가되어 있는지 확인 |
YAML은 들여쓰기에 민감합니다. 목록 항목 앞에는 보통 공백 두 칸을 사용하며 탭 문자를 섞어서는 안 됩니다. 편집 후에는 먼저 클라이언트의 문법 검사 결과를 확인한 다음 코어에 로드하세요. 오류가 86번째 줄을 가리키더라도 실제로 콜론이 빠졌거나 들여쓰기가 어긋난 위치는 85번째 줄일 수 있으므로 바로 앞 줄까지 함께 확인해야 합니다.
로컬 설정 편집: 먼저 파일 매핑 관계 확인하기
여러 Profile을 사용하는 환경에서 가장 흔한 실수는 config.yaml이라는 파일을 열어 수정했는데도 클라이언트 화면에 변화가 없는 경우입니다. 클라이언트가 실제로는 다른 캐시 파일을 실행 중이거나 실행 설정에 덮어쓰기 내용이 추가되어 있기 때문일 수 있습니다. 편집할 때는 디스크에서 파일 이름만 보고 추측하지 말고 Profile 세부 메뉴에서 파일을 열어야 합니다.
안전한 편집 순서
- 설정 목록에서 현재 활성화된 항목을 확인합니다.
- 해당 항목의 ‘파일 열기’, ‘설정 편집’ 또는 ‘폴더 열기’ 메뉴를 사용합니다.
- 원본 파일을 복사하고 사본 이름에 날짜와 용도를 추가합니다.
- 한 번에 한 영역만 수정합니다. 예를 들어 먼저
mixed-port를 바꾸고 확인한 뒤 DNS를 수정합니다. - 저장한 후 문법 검사와 설정 다시 불러오기를 실행합니다.
- 로그를 통해 코어가 예상한 파일을 읽었는지 확인합니다.
Mihomo에서 자주 사용하는 핵심 필드로는 mixed-port, allow-lan, mode, dns, tun, proxies, proxy-groups, rules가 있습니다. 필드를 수정하기 전 클라이언트에 별도 토글이 있는지 확인해야 합니다. 예를 들어 화면의 TUN 토글은 실행 중 덮어쓰기로 제어될 수 있습니다. YAML에 enable: false를 작성했더라도 클라이언트가 코어를 시작하기 전에 자체 설정을 병합하면 TUN이 활성화될 수 있습니다.
최종 설정을 확인해야 한다면 클라이언트에서 제공하는 ‘실행 설정’, ‘현재 설정’ 또는 디버그 내보내기 기능을 이용하세요. 이는 원격 구독, 로컬 덮어쓰기, 클라이언트 설정을 병합한 결과이므로 구독 캐시만 보는 것보다 Mihomo가 실제로 받은 내용에 가깝습니다.
오래된 Profile 정리: 먼저 비활성화한 뒤 삭제하기
설정 목록에 항목이 너무 많이 쌓이면 중복된 이름과 만료된 구독 때문에 잘못 전환할 가능성이 커집니다. 정리할 때는 현재 활성화된 항목부터 삭제하지 마세요. 먼저 정상 작동이 확인된 주 Profile로 전환하고 웹 페이지에 접속해 로그를 확인한 다음 오래된 항목을 처리합니다.
삭제 전 필요한 정보 보관하기
- Profile의 표시 이름, 출처 유형, 마지막 업데이트 시간을 기록합니다.
- 로컬 사용자 지정 설정은 먼저 YAML로 내보낸 뒤 목록 항목을 삭제합니다.
- 오래된 Profile에만 있는 규칙, 프록시 그룹 또는 DNS 매개변수가 없는지 확인합니다.
- 원격 구독은 현재 사용하는 항목만 남기고, 여러 이름이 같은 주소를 가리키지 않도록 정리합니다.
- 삭제 후 캐시 폴더를 확인해 클라이언트가 자동 관리하는 파일과 수동 백업 파일을 구분합니다.
설정을 ‘현재 사용’, ‘테스트 중’, ‘복구용’ 세 가지로 나누는 것이 좋습니다. 현재 사용 항목은 1~2개만 유지하고, 테스트 설정은 검증이 끝난 뒤 병합하거나 삭제합니다. 복구용 설정은 최근 안정 버전 하나만 보관하면 됩니다. 날짜로 이름을 지정한 사본이 몇 달 이상 오래되었다면 규칙과 노드 정보가 이미 만료되었을 수 있으므로 장기간 기본 설정으로 사용해서는 안 됩니다.
여러 설정 관리 시 자주 묻는 질문
Profile을 전환한 뒤 이전에 선택한 노드가 바뀐 이유는 무엇인가요?
노드 선택은 보통 프록시 그룹 이름과 노드 이름을 기준으로 저장됩니다. 새 Profile에 같은 이름의 노드가 없으면 클라이언트가 프록시 그룹의 기본 항목을 사용하거나 목록의 첫 번째 사용 가능한 항목으로 돌아갑니다. 전환 후에는 ‘노드 선택’, ‘자동 선택’ 등 주요 프록시 그룹을 다시 확인해야 합니다.
여러 Profile을 동시에 실행할 수 있나요?
대부분의 데스크톱 클라이언트는 한 번에 하나의 주 Profile만 동일한 Mihomo 코어에 전달합니다. 여러 코어를 직접 실행하려면 서로 다른 mixed-port, 제어 포트, DNS 수신 포트를 할당하고 시스템 프록시나 기본 경로를 동시에 가로채지 않도록 해야 합니다. 일반적인 사용 환경에서는 하나의 클라이언트 안에서 전환하는 방식이 적합합니다.
구독을 업데이트하면 프록시 그룹에서 수동으로 선택한 항목도 덮어써지나요?
원격 YAML은 프록시 그룹 정의를 업데이트하지만 클라이언트가 마지막 선택 항목을 별도로 저장할 수도 있습니다. 기존 노드가 계속 존재하면 보통 그대로 사용할 수 있습니다. 노드 이름이 바뀌거나 삭제되면 프록시 그룹은 사용 가능한 기본 항목으로 돌아갑니다. 업데이트 후에는 지연 시간과 현재 선택 항목을 확인해야 합니다.
config.yaml을 수정했는데 왜 적용되지 않나요?
먼저 현재 Profile에 연결된 파일을 편집했는지 확인한 뒤 설정을 다시 불러오세요. 클라이언트의 Merge, Mixin 또는 덮어쓰기가 같은 이름의 필드를 덮고 있는지도 확인해야 합니다. 포트 설정을 변경했다면 시스템 프록시도 함께 조정해야 합니다.
Profile 업데이트 주기는 어느 정도가 적당한가요?
일반적인 구독은 6~24시간마다 한 번 새로 고치면 됩니다. 규칙 변경이 적은 로컬 설정은 수동 업데이트만으로 충분합니다. 지나치게 짧은 주기는 중복 요청을 늘릴 뿐 노드 상태를 더 빠르게 확인해 주지는 않습니다. 노드 지연 시간 확인은 프록시 그룹의 상태 점검 기능이 별도로 수행해야 합니다.
반복해서 적용할 수 있는 Profile 관리 절차
여러 Clash 설정을 안정적으로 관리하려면 ‘출처, 파일, 실행 상태’를 서로 연결해 두는 것이 핵심입니다. 가져올 때 이름을 명확히 정하고, 전환 후 포트와 프록시 그룹을 확인하며, 업데이트 전에는 복구용 사본을 저장하세요. 로컬 수정은 덮어쓰기나 별도 Profile로 보존하면 됩니다. 설정 수가 늘어나도 현재 코어가 정확히 어떤 내용을 불러왔는지 빠르게 판단할 수 있습니다.
- 이름에 용도, 출처, 업데이트 방식을 포함합니다.
- 원격 구독과 로컬 테스트 설정을 분리해 저장합니다.
- 전환 후 코어, 포트, 프록시 그룹, 연결 로그를 확인합니다.
- 자동 업데이트되는 구독 캐시에 장기간 사용할 사용자 지정 수정을 직접 적용하지 않습니다.
- 크게 수정하기 전 날짜가 포함된 정상 작동 사본을 보관합니다.
- 정리할 때는 먼저 주 설정으로 전환한 뒤 오래된 항목을 삭제합니다.