왜 「설정은 맞는데」 체감만 느릴까
프록시 클라이언트에서 속도는 단일 슬라이더로 올라가지 않습니다. 로컬 DNS 해석이 먼저 느리면 연결 자체가 늦게 열리고, 구독 안의 중복·고장 노드가 많으면 자동 선택 그룹이 자꾸 실패·재시도를 반복합니다. 반대로 규칙이 지나치게 세분화되어 있으면 매치 비용과 로그·UI 갱신이 겹쳐져 체감이 무거워질 수 있습니다.
이 글은 「브랜드 이름」보다 설정 트리 안에서 실제로 손댈 수 있는 레버에 집중합니다. 네트워크 정책·법규는 지역·기관마다 다르므로, 허용된 용도와 본인 책임 범위 안에서만 적용하시기 바랍니다. 용어와 기본 흐름을 먼저 익히려면 Clash 사용 문서를 함께 보는 것을 권장합니다.
10가지 실전 팁
1. 구독 URL·프로필 중복을 줄인다
같은 노드 묶음을 여러 구독 링크로 중복 등록하면 이름 충돌·중복 헬스 체크·불필요한 다운로드가 늘어납니다. GUI에서 프로필을 여러 개 두었다면, 실제로 쓰는 것은 하나의 기준 프로필로 모으고 나머지는 백업용으로 분리하세요. 구독 서버가 느릴 때는 갱신 주기를 너무 짧게 잡기보다, 실패 시 재시도 백오프(앱이 지원하는 경우)를 활용하는 편이 회선에 부담이 적습니다.
2. 프로바이더·규칙 세트의 갱신 간격을 현실적으로 맞춘다
Rule Provider와 Proxy Provider는 편하지만, 짧은 interval은 깨어날 때마다 외부 요청을 쏩니다. 홈 네트워크나 모바일 핫스팟에서는 수 시간~하루 단위로도 충분한 경우가 많습니다. 정책 목록이 자주 바뀌는 환경이 아니라면, 수동 갱신 + 안정적인 interval 조합이 체감 지연과 배터리 소모를 동시에 줄이는 경우가 많습니다.
3. DNS 모드: fake-ip와 redir-host를 목적에 맞게 고른다
fake-ip는 로컬에서 빠르게 IP를 내어 주어 앱이 곧바로 연결을 시도하게 만들지만, 일부 소프트웨어·LAN 서비스와 상성이 어긋날 수 있습니다. redir-host 계열은 호환성은 좋아도 해석 경로가 길어질 수 있습니다. 증상이 「브라우저는 괜찮은데 특정 앱만 느리다」이면 DNS 모드·fallback DNS 구성을 의심하는 것이 좋습니다. DNS 전용 가이드가 필요하면 사이트 내 관련 글과 함께 문서의 DNS 섹션을 대조해 보세요.
4. 업스트림 DNS(DoH/DoT)는 지연·가용성을 같이 본다
공용 DoH 하나만 멀리 붙어 있으면, 매 요청마다 RTT가 그대로 누적됩니다. 가능하면 지리적으로 가깝고 SLA가 안정적인 업스트림을 쓰고, primary + fallback을 명시해 한쪽 장애 시 타임아웃이 길게 이어지지 않게 합니다. 회사망에서는 DoH 자체가 차단되는 경우도 있어, 그때는 정책에 맞는 대안을 찾아야 합니다(우회가 곧 허용은 아님).
5. 규칙 매치를 단순화하고, 로그 레벨을 낮춘다
수천 줄 규칙이 모두 고비용 패턴이면 CPU 사용이 늘고, 디버그 로그를 켠 채로 두면 디스크·UI가 병목이 됩니다. 일상 사용에서는 INFO 이하로 두고, 문제 재현 시에만 잠시 올리세요. GEOIP·도메인 서픽스 계열을 쓸 때는 가장 자주 타는 트래픽이 위쪽에 오도록 순서를 재배치하면 평균 매치 시간이 줄어듭니다.
6. 지연 테스트(url-test)의 URL·간격을 현실적으로 튜닝한다
테스트 타깃 URL이 CDN 뒤에 있거나 특정 리전으로만 붙으면, 「빠른 노드」 선정이 왜곡됩니다. 가능하면 자주 쓰는 서비스와 비슷한 경로를 쓰고, interval을 지나치게 짧게 하면 배터리·대역폭만 소모합니다. tolerance를 너무 좁게 잡으면 노드가 자주 갈아타며 TCP 세션이 재수립되어 체감이 나빠질 수 있으니, 흔들림이 큰 회선에서는 약간 여유를 두는 편이 낫습니다.
7. 노드 그룹 전략: url-test, fallback, load-balance의 역할 분리
fallback은 연결 실패 시 빠르게 다음 후보로 넘기기 좋고, url-test는 지속적으로 가벼운 노드를 고르기 좋습니다. load-balance는 다운로드에 유리할 수 있지만, 세션 고정이 필요한 사이트에서는 오히려 불안정해 보일 수 있습니다. 「한 그룹에 모든 정책을 우겨 넣기」보다 용도별로 그룹을 쪼개 규칙에서 참조하면 디버깅도 쉬워집니다.
8. TUN·시스템 프록시·혼합 모드의 오버헤드를 이해한다
TUN은 편의성이 크지만 스택에 따라 추가 홉·패킷 처리 비용이 붙습니다. 게임·실시간 음성처럼 RTT에 민감하면, 앱별로 시스템 프록시 경로가 나은 경우도 있습니다. 반대로 UWP·일부 샌드박스 앱은 TUN이 더 확실할 수 있습니다. 한 번에 모든 트래픽을 TUN으로 보내기보다, 규칙으로 예외(직접 연결)를 명시해 불필요한 터널링을 줄이는 것이 체감에 도움이 되는 경우가 많습니다.
9. 코어(Mihomo)와 GUI를 주기적으로 맞춘다
프로토콜 파서·TLS 스택·DNS 처리는 코어 업데이트마다 버그 픽스와 성능 개선이 들어옵니다. 구독은 최신인데 연결만 꼬이는 패턴은 구버전 파서에서 흔합니다. 릴리스 노트를 훑어 DNS·provider·특정 프로토콜 관련 수정이 있었는지 확인하고 올리세요. 설치 파일은 공식 다운로드 페이지에서 받는 흐름이 버전 관리에 유리합니다.
10. 피크 시간·물리 거리를 무시하지 않는다
노드 품질은 시간대에 따라 크게 변합니다. 저녁 시간대 혼잡이 심하면 아무리 튜닝해도 한계가 있습니다. 이때는 리전을 바꾸거나, UDP가 필요한 서비스와 그렇지 않은 서비스를 분리 그룹으로 타게 하는 편이 현실적입니다. 무엇보다 실측(지연·손실·다운로드 샘플)을 기준으로 가정을 검증하세요.
마무리 체크리스트
한 번에 열 개를 다 바꾸기보다, DNS → 구독·프로바이더 → 규칙 → 그룹·테스트 URL 순으로 바꾸고 각 단계마다 체감을 기록하는 편이 안전합니다. 로그를 켠 채 장시간 두지 말고, 문제가 재현될 때만 좁은 범위로 수집하세요.
규칙 기반 클라이언트는 한번 구조를 잡아 두면 앱·사이트 단위 제어가 매끄럽습니다. 비슷한 대역의 다른 도구들과 비교해도, 구독·DNS·프록시 그룹을 한 설정 트리에서 다루는 방식은 운영 부담을 줄이는 데 여전히 유리한 편입니다. 최신 코어와 검증된 배포본을 유지하면 연결 성공률과 재현성도 함께 좋아지는 경우가 많습니다.