Profile: 클라이언트에 저장하는 설정 프로필
Clash Profile은 보통 클라이언트가 관리하는 설정 프로필을 말합니다. 구독 링크에서 가져올 수도 있고, 로컬 YAML 파일을 불러올 수도 있습니다. FlClash는 프로필을 저장하고 업데이트하며 선택할 수 있게 한 뒤, 처리된 유효 설정을 Clash Meta 코어(mihomo)에 전달해 실행합니다. Profile은 개별 노드나 특정 프록시 그룹을 뜻하지 않습니다.
하나의 전체 설정에는 리스닝 포트, DNS, 프록시 노드, 프록시 그룹, 라우팅 규칙이 함께 정의될 수 있습니다. 예를 들어 mixed-port: 7890은 HTTP와 SOCKS를 함께 사용하는 프록시 포트를 지정하고, proxy-groups는 트래픽이 나갈 경로를 선택하며, rules는 연결을 어느 경로로 보낼지 정합니다. Profile을 전환하면 노드만 바뀌는 것이 아니라 이런 설정이 함께 달라질 수 있습니다.
- Profile 전환: 다른 설정 프로필을 선택하면 규칙, 노드 출처, 그룹 구성이 달라질 수 있습니다.
- 프록시 그룹 전환: 현재 설정은 그대로 두고, 특정 그룹에서 선택한 노드나 하위 그룹만 바꿉니다.
- 아웃바운드 모드 전환: 규칙·전역·직접 연결 중 처리 방식을 바꿉니다. 다른 구독 프로필로 자동 전환되지는 않습니다.
구독 설정과 로컬 설정의 차이
두 설정 모두 최종적으로는 코어가 읽을 수 있는 형식으로 만들어야 합니다. 차이는 주로 설정을 가져오는 곳과 관리 방식에 있습니다. 구독 설정은 원격 주소에서 내용을 가져오며 나중에 다시 받아올 수 있습니다. 로컬 설정은 사용자가 가져와 관리합니다. 원본 파일을 수정해도 클라이언트에 반영되는지는 가져온 방식에 따라 다르므로, 디스크의 파일과 계속 동기화된다고 단정할 수 없습니다.
| 항목 | 구독 설정 | 로컬 설정 |
|---|---|---|
| 내용 출처 | 원격 구독 주소에서 제공하는 내용 | 직접 작성하거나 가져온 YAML 파일 |
| 업데이트 방식 | 수동 새로고침 또는 클라이언트의 주기적 가져오기 | 수정 후 다시 가져오거나 클라이언트에서 저장 |
| 주요 용도 | 노드 및 서비스 제공자의 설정 변경을 지속적으로 반영 | 고정 규칙, 실험용 설정, 직접 관리하는 로컬 백업 |
| 수정 시 유의점 | 원격 내용을 직접 수정하면 다음 업데이트 때 덮어써질 수 있음 | 노드 인증 정보와 프로토콜 매개변수 변경을 직접 반영해야 함 |
구독 주소가 항상 완전한 YAML을 제공하는 것은 아닙니다
‘구독’은 콘텐츠를 가져오는 방식을 뜻할 뿐, 형식이 항상 같다는 의미는 아닙니다. 일부 주소는 완전한 Clash 설정을 제공하지만, 노드 목록만 제공하거나 다른 클라이언트용 형식으로 제공하기도 합니다. 다운로드가 완료되어도 활성화되지 않을 수 있습니다. 서비스 제공자가 Clash 또는 Clash Meta용이라고 명시한 주소를 선택하고, 현재 클라이언트와 코어가 지원하는 필드 및 프로토콜인지 확인하세요.
구독 URL의 쿼리 매개변수나 경로에 접속 정보가 포함될 수 있습니다. 문제를 확인할 때는 오류 메시지와 필드 이름, 민감한 정보를 가린 일부 내용만 공유하세요. 전체 URL을 공개 스크린샷, 문의 첨부 파일, 설정 예시에 넣지 마세요.
사용자 지정 규칙을 추가할 때는 저장 위치부터 확인하세요
FlClash의 UI 옵션, 설정 오버라이드, 원격 YAML이 최종 설정에 함께 영향을 줄 수 있습니다. 편집 기능과 설정 병합 방식은 버전에 따라 달라지므로, 구독 본문을 수정하면 변경 내용이 계속 유지된다고 가정하면 안 됩니다. 현재 버전에서 공식적으로 제공하는 오버라이드 기능을 우선 사용하세요. 적절한 기능이 없다면 로컬 사본을 별도로 저장하고 수정 사항을 기록해 두세요. 사본을 사용하면 원격 노드 변경도 직접 반영해야 합니다.
구독 가져오기와 자동 업데이트 주기
가져올 때는 ‘항목 추가’와 ‘해당 항목 활성화’를 구분하세요. ‘구독 추가 → 첫 가져오기 → 설정 확인 → 활성화 선택 → 새 연결로 검증’ 순서로 진행하는 것이 좋습니다. 화면의 메뉴 이름은 FlClash 버전에 따라 달라질 수 있으므로, 아래에서는 기능을 기준으로 설명합니다.
- 출처 추가: 설정 관리 화면에서 링크로 추가하는 기능을 선택하고 전체 구독 URL을 붙여 넣은 뒤, 용도를 알아보기 쉬운 이름을 입력합니다.
- 내용 확인: 첫 다운로드가 끝나면 노드나 프록시 그룹이 표시되는지 확인하세요. 업데이트 시간이 표시된다는 사실만으로 설정이 적용됐다고 볼 수는 없습니다.
- 설정 활성화: 새 항목을 현재 설정으로 지정하고, 파싱 실패나 알 수 없는 프록시 그룹, 포트 충돌 알림이 있는지 확인하세요.
- 아웃바운드 확인: 규칙 모드를 선택한 뒤 새 테스트 요청을 보내고, 연결 화면에서 적용된 규칙과 아웃바운드 경로를 확인하세요.
일반적인 사용은 24시간마다 업데이트하는 것부터 시작하세요
24시간은 관리하기 편한 시작점일 뿐, 코어가 요구하는 값은 아닙니다. 서비스 제공자가 노드를 자주 변경한다면 안내에 따라 6시간으로 줄일 수 있습니다. 요청 횟수 제한이 명시되어 있다면 해당 제한을 우선 따르세요. 구독을 자주 가져와도 노드 대역폭이 개선되거나 로컬 DNS 및 TUN 라우팅 문제가 해결되지는 않습니다.
- 단위를 먼저 확인하세요: 24시간은 1440분 또는 86400초입니다. 입력란의 단위가 ‘분’이라면 하루를 나타내기 위해 24를 입력하면 안 됩니다.
- 두 종류의 업데이트를 구분하세요: Profile의 원격 업데이트 주기와
proxy-providers안의interval은 서로 다른 설정입니다. 후자는 mihomo 설정에서 초 단위로 지정합니다. - 백그라운드 실행 조건을 확인하세요: 컴퓨터가 절전 모드에 있거나 클라이언트가 종료된 경우, 또는 모바일 운영체제가 백그라운드 실행을 제한하는 경우에는 설정한 시각에 맞춰 업데이트된다고 보장할 수 없습니다. 필요하면 앱을 열어 수동으로 업데이트하세요.
- 각 시간을 구분하세요: 최근 업데이트 시도 시각, 최근 업데이트 성공 시각, 구독 만료 시각은 서로 다른 정보입니다. 업데이트에 성공해도 계정 이용 기간이 연장되는 것은 아닙니다.
여러 설정의 이름 지정과 백업: 출처·용도·날짜
설정이 3개 이상이면 ‘구독 1’, ‘새 설정’ 같은 이름만으로는 잘못 선택하기 쉽습니다. ‘출처－용도－관리 방식’ 순서로 이름을 정해 보세요. 예: ‘회선 A－일상－원격’, ‘회선 B－예비－원격’, ‘일상 규칙－실험－로컬’. 날짜는 백업 이름에 넣는 편이 좋습니다. 예: ‘일상 규칙－백업－2026-11-03’.
설정 이름은 클라이언트에서 항목을 관리하기 위한 것으로, 규칙의 대상 이름으로 자동 사용되지 않습니다. 규칙은 YAML에 정의된 프록시 그룹 이름을 참조합니다. proxy-groups의 그룹 이름을 ‘일상 출구’에서 ‘기본 출구’로 바꾼다면, 해당 그룹을 참조하는 규칙과 다른 그룹도 함께 수정해야 합니다. 목록에 표시되는 Profile 이름만 바꾸는 경우에는 보통 이런 참조를 수정할 필요가 없습니다.
되돌릴 수 있는 상태를 하나 이상 유지하세요
- 수정 전: 현재 설정 이름, 아웃바운드 모드, 선택된 노드, 시스템 프록시와 TUN의 활성화 상태를 기록하세요.
- 백업 내용: YAML과 필요한 오버라이드 설정을 저장하세요. 기본 YAML만 내보내면 클라이언트에 별도로 저장된 매개변수가 빠질 수 있습니다.
- 저장 위치: 노드 비밀번호가 포함된 백업은 접근을 제한한 폴더에 보관하고, 공개 코드 저장소나 공유 클라우드 드라이브에 함께 두지 마세요.
- 오래된 항목 정리: 대체 설정이 정상적으로 시작되는지 확인한 뒤 중복 항목을 삭제하세요. 더 이상 사용할 수 없는 주소가 계속 자동 업데이트되도록 두지 마세요.
전환 후 연결과 규칙은 어떻게 적용될까요?
설정 선택, 코어의 정상적인 설정 로드, 앱의 새 연결에서 새 설정 사용은 각각 따로 확인해야 합니다. 클라이언트는 선택 상태를 먼저 저장한 뒤 코어 설정을 불러올 수 있습니다. YAML 오류나 존재하지 않는 프록시 그룹이 있으면 화면에서 선택된 것만으로 전환 완료를 확인할 수 없습니다. 로그와 연결 화면도 함께 살펴보세요.
새 연결과 기존 연결을 따로 확인하세요
새 설정이 정상적으로 로드된 뒤에는 새 연결이 보통 현재 모드와 규칙에 따라 처리됩니다. 이미 연결된 TCP 장시간 연결, 동영상 세션, 앱의 연결 풀은 새 노드로 자동 이전된다고 볼 수 없습니다. 클라이언트에 따라 연결을 즉시 닫기도 하고 그대로 유지하기도 하며, 동작은 구현과 사용 방법에 따라 달라집니다. 확인할 때는 새 요청을 보내고, 필요하면 클라이언트의 연결 종료 기능을 사용하거나 대상 앱을 다시 시작하세요.
장시간 연결이 유지되는 페이지를 새로고침한 결과만으로 전환 실패를 판단하지 마세요. 연결 화면에서 새 요청의 도메인, 적용된 규칙, 아웃바운드 경로를 확인할 수 있습니다. 브라우저 캐시, 연결 재사용, HTTP/3 때문에 한 번 새로고침하는 것만으로는 변경 사항이 명확히 드러나지 않을 수 있습니다. 새 탭을 열어도 실제 네트워크 연결이 새로 만들어진다는 보장은 없습니다.
모드·DNS·TUN이 Profile과 함께 바뀌지 않을 수 있습니다
시스템 프록시, TUN 모드, 일부 DNS 매개변수는 클라이언트의 전역 설정으로 관리되거나 오버라이드를 통해 기본 YAML에 영향을 줄 수 있습니다. Profile을 전환한 뒤 파일의 tun 또는 dns 내용만 보고 실제 상태를 단정하지 마세요. 화면의 스위치와 유효 설정을 확인하고, 특히 클라이언트가 여전히 전역 모드를 사용 중인지 살펴보세요.
예를 들어 설정 A는 mixed-port: 7890을 사용하고 설정 B는 mixed-port: 7891로 바꿉니다. 클라이언트가 포트를 덮어쓰지 않고 특정 앱에 127.0.0.1:7890을 직접 입력했다면, 설정을 전환한 뒤에도 앱은 이전 포트에 연결하려 합니다. 클라이언트가 관리하는 시스템 프록시와 앱에 직접 입력한 프록시 주소도 각각 확인해야 합니다.
로컬 설정 예시: 참조 관계부터 확인하기
아래는 로컬 Profile을 이해하기 위한 최소한의 직접 연결 예시입니다. profile-local-demo.yaml로 저장한 뒤 가져올 수 있습니다. 원격 프록시 노드는 포함되어 있지 않으며, ‘일상 출구’와 일치하는 모든 연결은 DIRECT로 나갑니다. 따라서 원격 프록시의 작동 여부를 확인하는 데 사용할 수 없습니다.
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
proxy-groups:
- name: 일상 출구
type: select
proxies:
- DIRECT
rules:
- DOMAIN-SUFFIX,example.com,일상 출구
- MATCH,일상 출구이 예시에는 두 단계의 참조가 있습니다. 규칙에 쓰인 ‘일상 출구’는 프록시 그룹 이름과 일치해야 하며, 그룹 안의 DIRECT는 코어에 내장된 아웃바운드입니다. 마지막 규칙인 MATCH는 앞선 규칙에 일치하지 않은 연결을 처리합니다. 실제 구독에는 중첩 프록시 그룹, 규칙 세트, 프록시 제공자가 포함될 수 있으므로 일부만 복사해 의존성이 모두 갖춰졌다고 생각하면 안 됩니다.
YAML 들여쓰기에는 공백을 사용하고 Tab은 사용하지 마세요. 가져올 때 포트가 사용 중이라는 알림이 뜨면 구독을 반복해서 새로고침하기보다 다른 프로그램이 7890 포트를 사용 중인지 먼저 확인하세요. 특정 프록시나 그룹을 찾을 수 없다는 알림이 나오면 이름의 철자와 참조 관계를 확인하세요.
자주 묻는 질문: 업데이트에 성공했는데 설정이 바뀌지 않아요
예비 설정을 새로고침했는데 현재 연결이 왜 그대로인가요?
항목을 업데이트하는 것과 활성화하는 것은 다릅니다. 업데이트한 항목이 현재 활성화된 Profile과 같은지 확인하세요. 예비 항목을 업데이트했다면 현재 실행 중인 설정이 바뀌지 않는 것이 정상입니다. 현재 항목을 업데이트했더라도 클라이언트가 설정을 다시 불러왔는지, 실제 내용에 차이가 있는지 확인해야 합니다.
전환한 뒤에도 노드 이름이 그대로인데, 전환에 실패한 건가요?
서로 다른 구독에서 같은 노드 이름을 사용할 수 있으며, 클라이언트가 같은 이름의 프록시 그룹에서 이전에 선택한 항목을 복원할 수도 있습니다. 노드 이름만 보지 말고 설정 이름, 규칙 내용, 새 연결의 아웃바운드 경로를 함께 확인하세요. 노드 이름이 바뀌거나 삭제된 경우에는 이전 선택이 복원되지 않을 수도 있습니다.
로컬 사본에 원격에서 추가된 노드가 반영되지 않는 이유는 무엇인가요?
로컬 사본은 보통 가져온 시점의 콘텐츠를 저장한 것입니다. 사본에서 업데이트 가능한 프록시 제공자를 직접 참조하지 않는 한, 원본 구독이 바뀌어도 노드가 자동으로 추가되지는 않습니다. 원격 노드를 계속 가져오면서 사용자 지정 규칙도 유지하려면 현재 클라이언트가 지원하는 오버라이드 방식을 사용하거나 프록시 제공자와 참조 관계를 올바르게 설정하세요.
문제를 확인할 때 권장하는 순서는 무엇인가요?
- 현재 활성화된 Profile 이름을 확인하고, 가장 최근에 정상적으로 로드된 기록을 살펴봅니다.
- 규칙·전역·직접 연결 모드를 확인하고, 프록시 그룹에서 현재 선택된 항목을 점검합니다.
- 프록시 포트, 시스템 프록시, TUN의 실제 상태를 확인합니다.
- 연결을 새로 만든 뒤 연결 화면에서 적용된 규칙과 아웃바운드 경로를 확인합니다.
- 문제가 계속되면 정상 작동이 확인된 백업으로 되돌리고, 변경 사항을 한 번에 하나씩 복구합니다.
Profile을 관리할 때는 설정의 출처와 업데이트 여부, 실행 상태를 구분하는 것이 중요합니다. 우선 설정 하나를 가져와 연결까지 확인한 다음 예비 설정이나 실험용 설정을 추가하세요. 전환할 때마다 새 연결을 확인하면 기존 세션, 전역 설정, 구독 내용을 한꺼번에 점검하느라 시간을 낭비하지 않을 수 있습니다.