Mixin과 프로필 편집(직접 수정)은 무엇이 다른가요?

Mixin은 보통 구독으로 받은 베이스 YAML 위에 로컬 조각을 깊게 병합하는 용도로 쓰이고, 프로필 전체를 저장소처럼 직접 덮어쓰면 다음 구독 갱신 때 충돌이 나기 쉽습니다. 원격을 유지하려면 Mixin·오버라이드 축을 쓰는 편이 안전합니다.

규칙만 앞이나 뒤에 붙이고 싶습니다.

rules 배열 앞쪽에 넣을지 뒤쪽에 넣을지는 병합 방식과 prepend 옵션에 따라 달라질 수 있습니다. MATCH 직전에만 넣고 싶다면 규칙 순서를 의식한 YAML 조각을 두고, 개념은 사용자 규칙 튜토리얼과 같이 읽으면 덜 헷갈립니다.

DNS를 오버라이드했는데 스포츠 앱만 이상해요.

fake-ip와 DIRECT 트래픽이 섞이면 일부 UDP·P2P가 기대와 다르게 보일 수 있습니다. DNS 블록만 바꿀 때는 enhance-mode, nameserver, fallback 순서를 한 번에 적지 말고 단계적으로 넣으며 로그로 확인하세요.

⚙️ 설정 2026년 5월 8일 ⏱ 약 18분 분량

Windows 11에서 Clash Verge Rev Mixin·프로필 오버라이드: 원격 구독은 그대로 두고 포트·DNS·규칙만 YAML·GUI로 덧씌우기 (2026)

한국어 검색으로 이 페이지를 찾는 분들은 보통 이렇게 말합니다. 공항 구독 YAML은 그대로 두고 싶은데 회사 노트북만 혼합 포트를 바꾸거나, 집망에서만 DNS enhancer 줄을 덧붙이거나, 특정 사이트만 rules 한 덩어리를 위에 얹고 싶다. Clash Verge Rev(Mihomo)의 Mixin·프로필 오버라이드가 바로 그 로컬 덧씌움 축입니다. 전체 설치·시스템 프록시·TUN 첫 실행은 Windows 11 Verge Rev 첫 설정과 역할을 나눕니다.

검색 의도 정리: 왜 Mixin을 쓰는가

원격 구독 URL은 제공자가 노드 목록과 기본 규칙을 한 번에 내려 주는 편이라 로컬만의 예외를 넣기가 애매합니다. 파일을 직접 고치면 다음 자동 갱신 때 덮이거나 손으로 머지해야 해서 운영 부담이 큽니다. Mixin·프로필 오버라이드는 그 위에 짧은 YAML 조각을 얹어 포트, DNS, 규칙 일부, 때로는 스니펫 수준의 프록시 그룹만 바꾸는 패턴입니다.

즉 사용자가 검색으로 말하는 「프로필 오버라이드 설정 방법」은 단일 버튼 이름이라기보다 베이스 + 로컬 병합이라는 행위를 가리킵니다. 구독 갱신 타이머 자체를 손보는 문제는 Clash Verge Rev 구독 자동 업데이트 간격 글과 축을 나누어 보세요.

Clash Verge Rev 화면에서 먼저 고정할 것

Windows 11에서 앱을 켠 뒤 어느 프로필이 지금 활성인지를 헤더나 프로필 목록에서 먼저 확인합니다. 오버라이드는 보통 현재 선택된 프로필 런타임에 붙습니다. 비활성 프로필 쪽 에디터만 열어 두고 「적용이 안 된다」고 느끼는 경우가 가장 흔한 착시입니다.

또 하나는 구독이 한 번이라도 정상 로드됐는지입니다. 베이스 YAML이 비어 있거나 오류로 파싱에 실패하면 그 위에 Mixin을 얹어도 증상은 같습니다. 초기 연결 문제는 Windows 11 로그·타임아웃 진단 순서를 먼저 밟는 편이 시간을 아낍니다.

💡 핵심 오버라이드 편집기를 연 상태에서 구독이 갱신되면 병합 결과가 바뀐 베이스를 기준으로 다시 계산됩니다. 「어제는 됐는데 오늘만 이상하다」면 최근 갱신 후 키 충돌이 없는지 의심하세요.

GUI 쪽: 메뉴 이름이 빌드마다 달라도 찾는 패턴

Clash Verge Rev는 릴리스마다 좌측 네비 라벨이 조금씩 바뀌지만 패턴은 비슷합니다. 설정(Settings) 또는 프로필(Profiles) 근처에서 Mixin, Profile, Editor, Override, Merge처럼 읽히는 항목을 찾습니다. 한국어 UI라면 편집, 병합, 추가 구성 류로 번역되기도 합니다.

영문 빌드 사용자는 mixin, patch, prepend 같은 단어가 붙은 탭만 기억해 두어도 검색과 커뮤니티 질문이 빨라집니다. 화면에 버튼이 없고 외부 에디터로만 열리는 포크도 있으니, 해당 버전의 릴리스 노트에서 프로필 디렉터리 경로를 함께 확인합니다.

1단계: YAML로 혼합 포트만 살짝 바꾸기

노트북에서 다른 툴과 포트 충돌이 날 때 가장 많이 손대는 값이 mixed-port와 외부 컨트롤러 포트 류입니다. 원격 베이스에 이미 같은 키가 있다면 오버라이드가 덮어쓸지 아래에 병합만 할지는 코어·앱 버전 조합에 따라 달라질 수 있으니, 저장 후 실제로 리스닝 중인 포트를 작업 관리자나 netstat로 한 번 확인합니다.

# Mixin fragment example (ports only)
mixed-port: 7890
port: 7891
socks-port: 7892

위는 개념 예시입니다. SOCKS나 HTTP를 아예 쓰지 않는 환경이라면 불필요한 포트 줄을 억지로 넣을 필요는 없습니다. 회사 보안 스캐너가 특정 대역만 허용한다면 그 제약에 맞춰 한 줄만 남기는 편이 안전합니다.

2단계: DNS 블록만 덧씌워 회선별로 나누기

집에서는 ISP DNS가 빠르고, 카페망에서는 DoH가 안정적일 수 있습니다. 베이스 구독의 dns: 블록을 통째로 바꾸기보다 오버라이드에서 nameserver·fallback·enhanced-mode 중 필요한 키만 조정하면 실험 폭이 줄어듭니다.

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
  fallback:
    - https://dns.google/dns-query

fake-ip를 켠 상태에서 특정 STUN·게임 UDP가 어긋나 보이면, 그 증상이 DNS 때문인지 규칙 때문인지를 로그로 분리해야 합니다. DNS와 분류 규칙을 같이 만지는 큰 그림은 Clash 입문 튜토리얼의 Rule·DNS 흐름과 맞물려 있습니다.

3단계: rules 상단에 짧은 예외만 얹기

예를 들어 사내 Git 호스트만 DIRECT로 보내고 나머지는 베이스 규칙을 따르게 하려면 rules 배열의 앞쪽에 소수 줄을 두는 방식이 흔합니다. 다만 prepend-rules 옵션을 UI에서 따로 주는 빌드도 있어, 편집기에 어떤 필드가 보이는지에 따라 YAML을 넣을 위치가 달라집니다.

rules:
  - DOMAIN-SUFFIX,corp.example,DIRECT
  - IP-CIDR,10.0.0.0/8,DIRECT

규칙은 위에서 아래로 첫 매칭이 이깁니다. 베이스 쪽에 이미 긴 목록이 있다면 내 오버라이드 줄이 실제로 어디에 끼어 들어갔는지를 런타임 설정 덤프나 로그로 확인하는 습관이 필요합니다. 그룹 이름 설계는 프록시 그룹 가이드와 함께 보면 DIRECT·커스텀 그룹 실수가 줄어듭니다.

YAML 직접 편집과 GUI 저장의 우선순위

어떤 버전은 에디터에서 저장한 뒤에도 다른 화면의 토글이 이전 값을 다시 쓰는 레이스가 있을 수 있습니다. 증상이 재현되면 「마지막에 손을 댄 쪽」을 한 가지로 줄이세요. 팀이 쓰는 경우 UI만 또는 저장소 YAML만처럼 규칙을 정해두면 장기 운영이 편합니다.

사용자 규칙을 더 넓게 다루는 패턴은 사용자 규칙 튜토리얼에서 PROCESS·DOMAIN 계열을 함께 정리합니다. 베이스 구독과 역할을 나누는 관점에서 병행 읽기 좋습니다.

구독 측 키와 같은 키가 충돌할 때

mixed-port, dns.enable, tun 같이 한 번만 있어야 하는 키가 양쪽에 모두 있으면 최종 값이 직관과 다를 수 있습니다. 이때는 (1) 베이스에서 제거할 수 없는지, (2) 오버라이드에서 다른 키로 우회할 수 있는지, (3) 아예 별도 프로필을 두고 전환하는지 중 하나를 고릅니다.

「한 프로필로 모든 회사」「한 프로필로 모든 가족」을 억지로 끼워 맞추면 충돌 디버깅이 길어집니다. PC마다 포트만 다른 정도라면 Mixin 한 장으로 끝나지만, DNS 정책이 완전히 다르면 프로필 분리이 총비용이 더 낮은 경우가 많습니다.

⚠ 주의 테스트용으로 tun·system proxy·allow-lan을 동시에 만지면 루프백·UWP 예외 문제로 증상이 겹칩니다. 한 번에 한 축만 바꾸고 Windows 11 UWP 루프백 논의와 섞이지 않게 나누세요.

적용 후 검증 순서(실측 습관)

저장 직후 (1) 코어 재시작 또는 앱이 안내하는 reload, (2) 혼합 포트에 실제로 클라이언트가 붙는지, (3) DNS 질의가 기대한 서버로 나가는지, (4) 새 규칙 줄이 로그에서 먼저 매칭되는지를 순서대로 봅니다. 한 번에 네 가지를 동시에 바꾸면 원인 역추적이 어렵습니다.

원격 URL이 리다이렉트 체인을 타는 제공자를 쓰는 경우, 브라우저에서 보이는 주소와 실제 코어가 보는 YAML이 달라 보일 수 있습니다. 이때는 오버라이드 YAML이 비어 있어도 「증상만 비슷」한 다른 이슈일 수 있으니 구독 FAQ의 HTTP 오류 절과 함께 보는 편이 안전합니다.

스크립트·외부 도구와 같이 쓸 때

PowerShell이나 작업 스케줄러로 프로필 파일을 주기적으로 덮어쓰는 스크립트가 있으면, GUI에서 저장한 Mixin과 파일 시스템 레벨 경쟁이 납니다. 자동화는 한 축으로 모으고 앱 내부 편집기는 읽기 전용으로만 쓰는 식으로 운영 규칙을 정하면 밤새 디버깅하는 일이 줄어듭니다.

Git으로 프로필을 버전 관리한다면 민감한 토큰이 히스토리에 남지 않게 별도 분리 파일을 .gitignore에 두는 패턴도 흔합니다. 팀 단위 표준에서는 「민감 정보는 환경 변수·로컬 오버라이드만」처럼 문서 한 줄이라도 남겨 두면 온보딩이 빨라집니다.

보안·프라이버시 관점의 짧은 체크

오버라이드에 도메인·사내 IP 대역을 노출하는 예외 규칙을 넣었다면, 스크린샷을 공유할 때 그 조각이 함께 노출되지 않는지 확인합니다. 포트를 넓게 열어 allow-lan을 켠 상태는 공용 Wi-Fi에서 특히 신중해야 합니다.

이 글은 특정 공항·노드 제공자를 전제로 하지 않습니다. URL·토큰은 릴리스 노트와 제공자 공지의 허용 사용 범위를 먼저 따릅니다.

자주 묻는 것

Mixin에 넣은 줄이 로그에 안 보입니다.

문법 오류로 조각 전체가 무시됐거나, 다른 화면에서 같은 키를 다시 덮어썼을 수 있습니다. 편집기의 YAML 검증 메시지와 코어 로드 오류를 먼저 보고, 활성 프로필이 맞는지도 다시 확인하세요.

Windows 업데이트 후에만 DNS 오버라이드가 이상해요.

OEM 추가 네트워크 필터나 Hyper-V 가상 스위치가 올라오면 DNS 경로가 바뀌는 경우가 있습니다. TUN·시스템 프록시 조합을 잠시 끄고 한 축씩 재현해 보세요.

macOS 글만 보면 단축키가 안 맞습니다.

이 페이지는 Windows 11 전제입니다. 메뉴 깊이는 비슷해도 단축키·트레이 동작은 다릅니다. 크로스 플랫폼을 쓰면 플랫폼별 체크리스트를 따로 두는 편이 덜 헷갈립니다.

정리

Clash Verge Rev에서 Windows 11 사용자가 Mixin·프로필 오버라이드로 할 일은 한 줄로 요약됩니다. 활성 프로필을 고정하고, 원격 구독 베이스는 그대로 둔 채 포트·DNS·규칙 조각만 YAML이나 GUI 편집기에 얹은 다음, 저장·재시작·로그로 최종 런타임 값을 확인합니다.

일부 전통적인「단일 토글 VPN」 스타일 앱은 내부 DNS·포트·분류 규칙을 거의 숨겨서 초반엔 편하지만, 회사 프록시나 스크립트 자동화처럼 세부 축을 나눠 조정해야 하는 순간에 다시 설정 화면을 열 때마다 같은 메뉴를 헤매게 되는 경우가 많습니다. Clash 계열은 같은 구독이라도 Mihomo 코어 위에서 YAML 조각으로 국소 변경을 남기기 쉽고, 규칙·DNS·프로세스 축을 분리해 실측하기 좋습니다. 신뢰 가능한 배포 경로에서 클라이언트를 고르고 싶다면 Clash 다운로드 페이지에서 호환 빌드를 확인한 뒤 설치해 보세요.

→ 보안 패치와 패키지 지문을 함께 보고 싶다면 Clash 받기 안내로 이동해 주세요.