Clash 문제 해결 매뉴얼

시작하기 전에: 점검 방법과 정보 수집

문제 해결은 운보다 방법이 중요합니다. 이 장은 구체적인 문제를 해결하지는 않지만, 이후 각 장에서 얼마나 빠르고 정확하게 점검할 수 있는지를 좌우합니다. 3분만 투자해 읽으면 이후 반복적인 시행착오로 낭비할 한 시간을 아낄 수 있습니다.

점검의 3가지 원칙

한 번에 변수 하나만 바꾸기.문제가 생기면 노드를 바꾸고 모드를 바꾸고 클라이언트를 재시작하고 컴퓨터까지 재부팅하는 사람이 많습니다. 결국 문제가 해결돼도 어떤 조치가 효과가 있었는지 알 수 없어 재발하면 다시 처음부터 헤매게 됩니다. 올바른 방법은 한 곳을 바꾸고, 한 번 확인하고, 기록을 남기는 것입니다.

자신에게서 가까운 쪽부터 바깥으로 점검하기.전체 경로는 '앱 → 시스템 프록시 / TUN → 클라이언트 → 노드 → 목표 사이트' 순서입니다. 왼쪽일수록 스스로 확인하기 쉽고, 오른쪽일수록 제3자에 의존합니다. 먼저 내 쪽 절반에 문제가 없는지 확인한 뒤 노드와 구독 서비스 제공업체를 의심해야 합니다. 순서를 반대로 하면 헛수고입니다.

매 단계마다 검증 동작이 있어야 합니다.'왠지 괜찮아진 것 같다'는 인정되지 않습니다. curl 명령 한 줄, 지연 시간 테스트 한 번, 특정 사이트 접속 결과 등 명확한 검증 수단이 필요합니다. 이 매뉴얼의 각 장에서는 해당하는 검증 방법을 함께 제시합니다.

시작 전 수집해야 할 정보

• 클라이언트 이름과 사용 중인 플랫폼(예: Clash Plus / Windows, Clash Verge Rev / Linux). 클라이언트마다 설정 위치는 다르지만 점검 로직은 공통입니다;
• 현재 프록시 모드: 규칙 / 전역 / 다이렉트, 그리고 TUN(가상 네트워크 어댑터) 모드 사용 여부;
• 구독 출처: 링크가 구독 서비스 제공업체에서 직접 발급된 것인지, 변환 서비스를 거친 것인지;
• 클라이언트 로그에 남은 최근 오류 줄 — 거의 모든 클라이언트에 로그 패널이 있으니 먼저 레벨을 info로 맞춰 한 번 재현해 보세요;
• 문제가 '원래부터 그랬는지' 아니면 '어떤 변경 이후에 생겼는지'. 후자라면 해당 변경 사항을 되돌리는 것이 점검보다 훨씬 빠른 경우가 많습니다.

증상 빠른 조회표

어떤 장을 봐야 할지 모르겠다면 아래 표에서 증상을 먼저 찾아 장 이름을 클릭해 바로 이동하세요.

증상 1: 프록시를 켰는데 인터넷이 전혀 안 됨

결론부터 말하면 이런 문제의 90%는 두 곳에서 발생합니다 — 트래픽이 클라이언트로 아예 들어가지 않음(시스템 프록시가 설정되지 않았거나 다른 프로그램이 가로챔), 또는 클라이언트로는 들어갔지만 나가지 못함(모드 선택 오류, 규칙 차단, 노드 전체 장애). 명령 하나로 이 두 경우를 구분할 수 있으니 재설치를 서두르지 마세요.

1단계: curl로 클라이언트 포트에 직접 요청

클라이언트 설정 페이지를 열어 믹스드 포트를 확인하세요(기본값은 보통 7890이지만 반드시 자신의 클라이언트에 표시된 값을 기준으로 하세요, 인터넷 튜토리얼을 그대로 베끼지 마세요). 그런 다음 터미널 / 명령 프롬프트에서 실행합니다:

curl -x http://127.0.0.1:7890 -I https://www.gstatic.com/generate_204

이 명령은 시스템 프록시를 우회해 트래픽을 강제로 클라이언트 포트로 보냅니다. 결과는 두 가지뿐입니다:

• 204 또는 어떤 HTTP 응답 헤더가 반환됨: 클라이언트와 노드 쪽은 정상이며, 문제는 "트래픽이 들어오지 않음"입니다 — 다음 절로 이동해 시스템 프록시를 확인하세요;
• 연결 거부 / 타임아웃 오류: 트래픽은 클라이언트에 들어갔지만 나가지 못하는 상태이며, 문제는 클라이언트 설정이나 노드에 있습니다 — "트래픽이 나가지 못함" 절로 이동하세요.

트래픽이 들어오지 않는 경우: 시스템 프록시와 브라우저 확장 프로그램 확인

클라이언트에서 "시스템 프록시" 스위치가 켜져 있는지 확인한 뒤, 시스템 설정에서 프록시가 실제로 기록됐는지 대조하세요(플랫폼별 확인 위치는 시스템 프록시 장의 표 참고). 기록됐는데도 안 된다면 "트래픽을 가로채는" 세 가지 의심 대상을 집중적으로 확인하세요:

• 브라우저 프록시 확장 프로그램: SwitchyOmega 같은 확장 프로그램은 시스템 프록시보다 우선순위가 높습니다. 확장 프로그램에 만료된 프록시가 설정돼 있으면 브라우저가 완전히 끊깁니다. 확장 프로그램을 "시스템 프록시"로 전환하거나 비활성화한 뒤 다시 시도하세요;
• 다른 프록시 프로그램의 잔여물: 이전에 설치했던 프록시 도구가 완전히 제거되지 않아 종료 시 시스템 프록시를 복원하지 않았거나, 부팅 시 자동 실행되어 현재 클라이언트와 서로 덮어쓰는 경우입니다. 작업 관리자에서 검색해 사용하지 않는 프로그램을 완전히 종료하세요;
• 보안 소프트웨어와 기업 정책: 일부 보안 소프트웨어는 프록시 설정을 잠글 수 있고, 회사 PC는 그룹 정책으로 프록시가 강제될 수 있습니다. 이런 환경에서는 먼저 잠금을 해제해야 합니다.

트래픽이 나가지 못하는 경우: 모드와 규칙 확인

1. 프록시 모드를 확인하세요. 다이렉트 모드에서는 모든 트래픽이 노드를 거치지 않으므로, 잘못 켜져 있으면 프록시가 켜져 있어도 아무 의미가 없습니다. 초보자가 이 스위치를 잘못 건드리는 경우가 꽤 많습니다.
2. 규칙 모드에서는 클라이언트의 연결 / 로그 패널을 열고 접속되지 않는 사이트에 한 번 접속해, 이 연결이 어떤 규칙에 매칭되어 어느 정책 그룹으로 분류됐는지 확인하세요. REJECT에 매칭됐다면 규칙이 차단한 것이고, 매칭된 정책 그룹에서 선택된 노드가 이미 죽었다면 다른 노드로 바꾸면 됩니다.
3. "전역 테스트"를 한 번 해보세요: 전역 모드로 전환해 방금 지연 시간이 정상이었던 노드를 직접 선택한 뒤 접속하세요. 전역 모드에서는 되고 규칙 모드에서는 안 된다면, 규칙이나 정책 그룹 선택의 문제로 거의 확정할 수 있습니다.

TUN과 시스템 프록시를 동시에 켰을 때의 함정

TUN 모드와 시스템 프록시를 동시에 켜면 트래픽 경로를 추론하기가 매우 어려워집니다. 일부 연결은 가상 네트워크 어댑터를 타고 일부는 시스템 프록시를 타서, 로그가 서로 모순되어 보입니다. 점검 중에는 하나의 경로만 남겨두세요 — TUN을 끄고 시스템 프록시만 쓰거나, TUN을 켜고 시스템 프록시를 끄는 식으로 하다가 문제를 찾은 뒤 평소 조합으로 복원하세요.

증상 2: 노드 지연 시간 테스트 타임아웃

지연 시간 목록에 "타임아웃"이 줄줄이 뜨면 확실히 놀랍지만, 먼저 두 가지를 구분해야 합니다. 지연 시간 테스트 타임아웃이 노드를 쓸 수 없다는 것과 완전히 같지는 않습니다. 지연 시간 테스트는 노드가 고정된 테스트 주소에 접속하도록 하는 것으로, 일부 노드는 테스트 주소와 호환이 나빠도 실제 접속은 정상일 수 있습니다. 반대로 지연 시간 숫자는 좋아 보이는데 실제로 사용하면 페이지가 열리지 않는 경우도 있습니다. 최종적으로는 실제 접속 여부를 기준으로 하고, 지연 시간은 참고용일 뿐입니다.

전부 타임아웃: 노드를 탓하기 전에 로컬과 구독을 먼저 확인

모든 노드가 동시에 타임아웃되는 경우, 노드가 전부 동시에 장애가 났을 가능성은 오히려 낮고, 대부분 사용자 쪽의 문제입니다:

1. 로컬 네트워크가 정상인지 확인: 프록시를 끄거나(또는 다이렉트 모드로 전환) 국내 사이트를 열어보세요. 로컬에서도 안 되면 먼저 로컬 네트워크를 고쳐야 하며, 클라이언트의 문제가 아닙니다;
2. 구독이 아직 유효한지 확인: 구독 서비스 만료, 트래픽 소진, 또는 서비스 제공업체가 링크를 재설정한 경우 전체 노드가 한꺼번에 무효화됩니다. 다이렉트 상태에서 서비스 제공업체 공식 사이트에 로그인해 상태를 확인하고, 클라이언트에서 구독을 한 번 수동으로 업데이트하세요;
3. 테스트 주소 확인: 일부 클라이언트는 지연 시간 테스트 URL을 커스터마이즈할 수 있는데, 원래부터 접속 불가능한 주소로 바뀌어 있으면 당연히 전부 타임아웃으로 나옵니다. 기본값인 generate_204 계열 주소로 되돌려 다시 테스트하세요;
4. 클라이언트를 바꿔 교차 검증: 같은 구독을 다른 클라이언트에 가져와 보세요(다운로드 페이지에 5개 플랫폼 모두 대안이 있습니다). 다른 클라이언트에서는 정상이라면 문제는 원래 클라이언트의 설정에 있으며, 포트, TUN, DNS 세 곳을 중점적으로 재확인하세요.

일부만 타임아웃: 노드 쪽 문제 판단

일부 노드만 타임아웃되는 경우는 오히려 처리하기 쉽습니다:

• 지역별로 한꺼번에 타임아웃: 특정 국제 회선의 장애나 점검일 수 있습니다. 다른 지역 노드로 우선 버티고 몇 시간 뒤 다시 확인하세요;
• 특정 노드 몇 개가 계속 타임아웃: 해당 노드가 이미 오프라인인데 구독에서 정리되지 않았을 가능성이 큽니다. 구독 서비스 제공업체에 피드백하세요;
• 저녁 피크 시간에 전체적으로 느려지고 간헐적 타임아웃: 회선 혼잡의 전형적인 증상으로, 속도 저하 장에서 다룹니다. 비인기 지역 노드로 바꾸면 완화됩니다;
• 네트워크 환경을 바꾼 뒤 한꺼번에 타임아웃: 일부 네트워크(교내망, 기업망)는 특정 포트나 프로토콜을 차단합니다. 같은 구독 내의 다른 프로토콜, 다른 포트의 노드를 시도해 보세요.

증상 3: 구독 가져오기 또는 업데이트 실패

구독 문제는 오류 메시지가 대체로 명확하다는 장점이 있지만, 많은 클라이언트가 오류를 로그 안에 접어 넣어 팝업으로 띄우지 않는다는 단점도 있습니다. 가져오기 / 업데이트에 실패하면 먼저 로그 패널을 열어 빨간 글자로 표시된 줄을 찾고, 아래 표를 참고해 대응하세요.

오류 메시지 대조표

명령으로 구독 링크 수동 검증

링크가 문제인지 클라이언트가 문제인지 확실치 않다면, curl로 클라이언트가 구독을 받아오는 것을 한 번 시뮬레이션해 보세요(예시 링크는 가상의 것이니 자신의 링크로 바꾸세요):

curl -A "clash" -I "https://example.com/api/sub?token=xxxx"

200이 반환되고 응답 헤더에 subscription-userinfo 같은 필드가 보이면 링크 자체는 정상이며 문제는 클라이언트 쪽에 있습니다. 404 / 403이 반환되면 서비스 제공업체 관리 페이지에서 바로 새 링크로 교체하세요. -A "clash" 매개변수에 주의하세요: 많은 구독 서비스가 User-Agent에 따라 다른 형식을 내려주므로, 브라우저로 직접 열어 본 내용과 클라이언트가 받아오는 내용이 다를 수 있습니다. 검증할 때는 clash 계열 UA를 붙여야 참고 가치가 있습니다.

가져오기는 성공했는데 노드 목록이 비어 있음

이런 "가짜 성공"은 대부분 형식 문제입니다. 구독이 Clash 설정이 아니라 범용 공유 형식으로 반환되었거나, 오래된 코어의 클라이언트가 새로운 프로토콜 노드를 만나 통째로 건너뛰는 경우입니다. 대응 방향은 두 가지입니다. 하나는 서비스 제공업체에 Clash 형식 전용 구독 링크를 요청하는 것이고, 다른 하나는 mihomo 코어를 쓰는 클라이언트인지 확인하는 것입니다(다운로드 페이지에 있는 주력 클라이언트는 모두 그렇습니다). 새로운 프로토콜 지원이 완전하고 예전 형식과의 호환성도 더 좋습니다.

구독 관련 개별 질문(자동 업데이트 간격, 여러 구독 공존, 트래픽 정보 미표시 등)은 자주 묻는 질문의 "설치 및 설정" 분류에 모아두었습니다.

증상 4: 연결은 되는데 속도가 느림

"느림"은 가장 찾기 어려운 증상입니다. 병목이 경로의 어느 구간에나 있을 수 있기 때문입니다. 이 장의 핵심 방법은 한마디로, 먼저 교차 테스트로 병목을 특정 구간에 위치시킨 뒤 그 구간을 최적화하는 것입니다. 무작정 구독을 바꾸지 마세요.

3단계 교차 위치 파악법

1. 같은 노드로 다른 목표 테스트: 현재 노드로 서로 다른 사이트 3~4개를 열어보세요. 전부 느리면 노드나 로컬을 의심하고, 특정 사이트만 느리면 그 사이트 자체 문제거나 이 회선과 호환이 안 좋은 것이니 노드 지역을 바꾸면 됩니다;
2. 같은 목표로 다른 노드 테스트: 서로 다른 지역의 노드 두세 개로 같은 사이트에 접속해 보세요. 어떤 노드로도 느리면 로컬을 중점적으로 확인하고, 지역을 바꾸면 빨라지면 원래 노드가 혼잡한 것입니다;
3. 다이렉트로 로컬 기본 속도 테스트: 다이렉트 모드로 전환해 로컬 속도 테스트를 한 번 해보세요. 다이렉트에서도 느리면 먼저 광대역과 Wi-Fi 문제를 해결해야 합니다. 프록시가 기본 속도보다 빠를 수는 없습니다.

노드 쪽: 혼잡, 배율, 프로토콜

저녁 피크 시간에 느려지는 것은 공유 회선의 일반적인 현상입니다. 비인기 시간대는 빠르고 인기 시간대는 느리면 혼잡으로 거의 확인된 것이며, 비인기 지역 노드로 바꾸는 것이 가장 직접적인 완화법입니다. 또한 구독에 표시된 트래픽 배율에도 주의하세요. 배율이 높은 노드는 보통 더 비싼 회선을 타서 속도 체감도 다른 경우가 많으니, 사용할 가치가 있는지는 스스로 판단해야 합니다. 같은 서비스 제공업체가 여러 프로토콜 입구를 제공한다면 서로 전환해 비교해 보세요. 프로토콜마다 네트워크 환경에 따른 성능 차이가 꽤 큽니다.

클라이언트 쪽: 모드와 설정

• 평소에는 규칙 모드를 쓰고 전역 모드는 켜두지 마세요: 전역 모드에서는 국내 사이트 접속도 노드를 거쳐야 해서 모든 트래픽이 좁은 문으로 줄 서는 것과 같습니다. 규칙 모드로 다이렉트 트래픽은 다이렉트로 보내는 것이 속도와 사용성 면에서 최선입니다;
• 로그 레벨을 info로 되돌리기: debug 레벨은 방대한 로그를 기록해 장기간 켜두면 성능에 부담이 됩니다. 점검이 끝나면 반드시 되돌리세요;
• 다중 프록시가 겹쳐 있는지 확인: 정책 그룹에서 "릴레이 / 체인" 유형 그룹을 선택했거나, 클라이언트 바깥에 다른 프록시 도구를 한 겹 더 씌운 경우입니다. 홉이 하나씩 늘어날수록 속도 대가를 치러야 합니다;
• 규칙 세트가 너무 큼: 커스텀 규칙이 수만 줄 쌓여 있고 작성 방식이 비효율적(대량의 정규식)이면 매칭 부담이 커집니다. 규칙을 정리하거나 규칙 세트(rule-provider)로 바꿔 필요할 때만 불러오도록 하세요.

내 기기와 네트워크 환경 쪽

Wi-Fi 신호가 약하거나, 2.4G 대역이 혼잡하거나, 라우터 성능이 부족하면 전체 경로의 하한선이 됩니다. 특히 라우터에서 코어를 직접 구동하는 방식에 대해 말씀드리면, 소프트웨어 라우터 / 바이패스 라우터의 성능이 부족할 때 프록시 구동 부담이 집 전체 네트워크 속도를 직접 떨어뜨립니다. 선택 방향은 블로그의 라우터에서 mihomo 코어 직접 구동 배포 개요를 참고하세요. 그 외에도 다운로드 도구나 클라우드 동기화가 백그라운드에서 업로드 대역을 다 쓰고 있는지 확인하세요. 업로드가 가득 차면 모든 연결의 성능이 함께 무너집니다.

증상 5: DNS 해석 오류

DNS는 가장 눈에 잘 안 보이는 유형의 문제로, 증상이 매우 다양합니다. 노드 지연 시간은 모두 정상인데 페이지가 로딩만 계속되거나, 일부 다이렉트 사이트가 이상한 지역으로 해석되거나, 로컬 네트워크 기기가 갑자기 안 잡히는 경우입니다. 노드와 시스템 프록시 문제를 배제했는데도 이상하다면 대부분 DNS 문제입니다.

먼저 fake-ip와 redir-host 이해하기

Clash 계열 코어의 DNS에는 두 가지 강화 모드가 있습니다. fake-ip는 각 도메인에 예약 대역의 가짜 IP를 먼저 반환하고, 연결이 들어온 뒤 도메인 기준으로 규칙을 매칭합니다. 속도가 빠르고 규칙 매칭이 정확해 현재 주류 기본값입니다. redir-host는 실제 해석 결과를 반환하며 호환성이 필요한 상황에서 사용합니다. 두 방식의 세부 차이와 적용 상황은 용어 매뉴얼에 관련 항목이 있고, 블로그의 DNS 설정 상세 해설에서 더 자세히 다룹니다. 여기서는 점검 방법만 설명합니다.

대표 증상 대조

• 페이지가 로딩만 계속되지만 노드 지연 시간은 정상: 대부분 nameserver에 설정한 상위 DNS를 사용할 수 없어 해석 단계에서 멈춘 것입니다. 접속 가능한 DoH 주소로 바꿔 다시 시도하세요;
• 일부 국내 사이트가 해외로 해석되어 로딩이 이상함: 분기 처리가 fallback의 해외 해석 결과를 참조한 것입니다. fallback-filter에 geoip 기반 처리가 설정되어 있는지 확인하세요;
• 로컬 네트워크 기기, NAS, 프린터가 안 잡힘: fake-ip가 로컬 네트워크 도메인까지 가로챈 것입니다. *.lan, +.local 같은 항목을 fake-ip-filter에 추가하세요;
• 클라이언트를 끈 뒤에도 한동안 인터넷이 이상함: 시스템에 fake-ip 대역의 해석 결과가 캐시된 것입니다. 시스템 DNS 캐시를 한 번 지우면 복구됩니다.

바로 적용할 수 있는 DNS 설정 예시

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "+.local"
    - "+.msftconnecttest.com"
  nameserver:
    - https://223.5.5.5/dns-query
    - https://doh.pub/dns-query
  fallback:
    - https://1.1.1.1/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN

생각은 간단합니다. nameserver는 일상적인 해석을 담당하며 다이렉트로 접속 가능하고 응답이 빠른 곳을 선택합니다. fallback은 해외 도메인의 대안을 담당하며, fallback-filter의 geoip 규칙과 함께 작동합니다. 해석 결과가 국내 IP면 nameserver를 신뢰하고, 그렇지 않으면 fallback 결과를 채택해 오염을 방지합니다.

변경 후 검증 방법

설정을 다시 불러온 뒤, 클라이언트의 DNS 리스닝 포트로 직접 쿼리를 한 번 보내보세요(위 설정에서 지정한 1053 포트에 해당):

nslookup -port=1053 www.gstatic.com 127.0.0.1

fake-ip 모드에서 198.18로 시작하는 주소가 반환되면 정상 작동입니다. 또한 이전 결과가 판단을 방해하지 않도록 시스템 캐시를 한 번 지우는 것도 기억하세요:

# Windows
ipconfig /flushdns

# macOS
sudo killall -HUP mDNSResponder

증상 6: 시스템 프록시 미작동

원리를 먼저 이해하면 이후의 이상한 현상들이 모두 설명됩니다. 클라이언트에서 "시스템 프록시"를 켠다는 것은 본질적으로 운영체제의 네트워크 설정에 HTTP/SOCKS 프록시 주소를 등록하는 것일 뿐이며, 앱이 이 등록 정보를 읽을지 말지는 전적으로 앱의 선택입니다. 브라우저는 읽으므로 프록시를 타지만, 많은 명령줄 도구와 일부 데스크톱 앱은 읽지 않아서 여전히 다이렉트로 연결됩니다. 이건 오류가 아니라 원래 그런 구조입니다.

플랫폼별 시스템 프록시 확인 위치

클라이언트의 스위치는 켜져 있는데 시스템 설정에는 비어 있다면 쓰기가 실패한 것입니다. 클라이언트가 네트워크 설정을 변경할 권한을 얻었는지, 그리고 다른 프로그램이 반복적으로 되돌리고 있는지(잔여 프록시 도구, 일부 보안 소프트웨어가 이런 일을 합니다) 확인하세요. Linux 데스크톱 환경은 함정이 더 많습니다. GNOME과 KDE는 각각 별도의 프록시 설정을 가지고 있고 터미널은 환경 변수를 따르는 등 세 가지가 서로 연동되지 않습니다. 배포 세부 사항은 블로그의 Linux 두 가지 배포 경로를 참고하세요.

명령줄과 개발 도구: 따로 설정해야 함

터미널의 curl, pip, npm 같은 도구는 기본적으로 시스템 프록시를 읽지 않으며, 환경 변수를 이용해야 합니다(포트는 실제 클라이언트 포트로 바꾸세요):

export https_proxy=http://127.0.0.1:7890
export http_proxy=http://127.0.0.1:7890
export all_proxy=socks5://127.0.0.1:7891

Git은 자체 설정 항목이 있어 흔히 git config --global http.proxy http://127.0.0.1:7890 형태로 씁니다. 사용하지 않을 때는 --unset으로 해제하는 것을 기억하세요. 데스크톱 앱에 "네트워크 설정"이나 "시스템 프록시 사용" 스위치가 있다면 앱 내에서 켜는 것이 전역으로 이리저리 손대는 것보다 훨씬 깔끔합니다.

일일이 설정하기 싫다면: TUN 모드 사용

TUN 모드는 가상 네트워크 어댑터를 만들어 네트워크 계층에서 모든 트래픽을 처리하며, 어떤 앱의 협조도 필요하지 않습니다. 시스템 프록시가 관리할 수 없는 명령줄, 게임, UWP 앱까지 모두 커버할 수 있습니다. 대가는 관리자 / 시스템 확장 권한이 필요하고 DNS 설정을 올바르게 해야 한다는 것입니다(앞 장의 fake-ip 방식과 함께 사용). 활성화 입구와 권한 부여 절차는 클라이언트마다 다르며, 사용 가이드에 관련 항목이 있습니다. 개념 설명은 용어 매뉴얼의 TUN 항목을 참고하세요. TUN을 켠 뒤에는 시스템 프록시를 끄는 것을 권장합니다. 이유는 증상 1에서 언급한 "하나의 경로만 남기기" 원칙과 같습니다.

증상 7: 클라이언트 충돌 또는 실행 불가

충돌이나 강제 종료는 무섭게 보이지만 실제로는 원인이 가장 집중된 유형입니다. 설정 파일 문법 오류와 포트 충돌 두 가지를 합치면 대부분의 사례를 커버합니다. 아래 순서대로 확인하면 보통 10분 안에 결론이 나옵니다.

첫 번째 의심 대상: 설정 파일 문법

클라이언트가 새 구독을 가져온 직후나 설정을 직접 수정한 직후부터 강제 종료가 시작됐다면 설정 문제로 거의 확정할 수 있습니다. 가장 확실한 검증 방법은 코어로 직접 문법 검사를 하는 것입니다. mihomo 코어에는 검증 매개변수가 내장되어 있습니다(코어는 다운로드 페이지의 코어 영역에서 받을 수 있습니다):

mihomo -t -f /path/to/config.yaml

오류가 있으면 줄 번호와 원인을 바로 알려줍니다. 직접 설정을 수정할 때 흔히 나오는 세 가지 초보 실수는 YAML 들여쓰기에 Tab을 쓰거나 계층이 맞지 않는 경우, 복사·붙여넣기 중 한글 또는 중국어 따옴표가 섞인 경우, 같은 계층에 중복된 키가 있는 경우입니다. 하나씩 대조해서 고치면 됩니다. 원인을 못 찾겠다면 일단 이전에 정상이었던 설정으로 되돌려 클라이언트가 먼저 돌아가게 하세요.

두 번째 의심 대상: 포트 충돌과 잔여 프로세스

이전 클라이언트 인스턴스가 완전히 종료되지 않았거나 다른 프로그램이 같은 포트를 점유하고 있으면 새 인스턴스가 실행되지 않는 것은 당연합니다. 먼저 어떤 프로세스가 포트를 점유하고 있는지 확인하세요:

# Windows
netstat -ano | findstr 7890

# macOS / Linux
lsof -i :7890

점유 중인 프로세스를 찾으면 종료하거나, 클라이언트 설정에서 다른 포트 조합으로 바꾸세요. 부팅 시 자동 실행 항목에 프록시 클라이언트가 두 개 이상 들어있어 서로 충돌하고 있지 않은지도 함께 확인하세요 — 하나만 남기세요.

로그 보는 법 익히기

위 방법을 모두 배제했는데도 여전히 충돌한다면 로그로 판단해야 합니다. 현재 주력 클라이언트(Clash Plus, Clash Verge Rev, FlClash 등)는 모두 로그 페이지나 "로그 디렉터리 열기" 입구를 제공합니다. 로그 레벨을 debug로 맞추고 충돌을 한 번 재현한 뒤, 로그의 마지막 몇 줄을 확인하세요 — 충돌 직전의 마지막 기록이 대개 문제가 발생한 모듈을 가리킵니다. 이해하기 어려운 오류는 키워드로 자주 묻는 질문의 "문제 해결" 분류를 검색해 보세요. 흔한 오류는 대부분 항목으로 정리되어 있습니다.

깨끗하게 재설치하는 올바른 방법

1. 먼저 백업: 구독 링크를 내보내거나 따로 적어두고, 커스텀 규칙과 설정 파일을 다른 곳에 복사해 두세요;
2. 제거하고 잔여물 정리: 제거 후 설정 디렉터리를 수동으로 삭제하세요(위치는 클라이언트의 "설정 디렉터리 열기" 입구 참고). 남아 있는 잘못된 설정이 "재설치해도 계속 충돌하는" 가장 큰 원인입니다;
3. 재설치 후 단계적으로 복원: 먼저 설치해 빈 설정으로 실행되는지 확인한 뒤 구독을 가져오고, 커스텀 내용을 단계적으로 다시 추가하면서 매 단계마다 확인하세요. 문제가 되는 부분은 자연히 드러납니다;
4. 클라이언트를 바꿔 교차 검증: 같은 플랫폼에서 다른 클라이언트로 바꿔보세요(다운로드 페이지에 각 플랫폼마다 2~4개 선택지가 준비되어 있으며 Clash Plus를 우선 추천합니다). 같은 설정이 다른 클라이언트에서도 충돌하면 설정 문제이고, 다른 클라이언트에서 정상이면 원래 클라이언트를 다시 깊게 파고들어야 합니다.

증상 8: 모바일 전용 (Android / iOS)

휴대폰 문제는 자체적인 논리가 있습니다. 데스크톱의 문제는 대부분 설정에 있지만 모바일의 문제는 대부분 시스템 권한과 백그라운드 정책에 있습니다. 데스크톱식 사고를 그대로 휴대폰에 적용하면 자주 방향을 잘못 잡으므로 별도의 장으로 구성했습니다.

Android: 권한과 백그라운드가 두 가지 핵심 관문

• VPN 권한: Android 클라이언트는 VpnService로 트래픽을 처리하며, 처음 실행할 때 나오는 권한 팝업에서 반드시 허용을 눌러야 합니다. 이후 시스템 설정에서 권한을 취소했거나 다른 VPN 앱이 통로를 가져가면(시스템은 동시에 하나의 VPN만 활성화할 수 있음) 클라이언트가 조용히 무효화됩니다. 설정 → 네트워크 → VPN에서 현재 활성화된 것이 무엇인지 확인하세요;
• 배터리 최적화로 인한 백그라운드 종료: 국내 커스텀 시스템의 공격적인 절전 정책이 "쓰다가 갑자기 끊기는" 가장 큰 원인입니다. 클라이언트를 배터리 최적화 화이트리스트에 추가하고 백그라운드 실행과 자동 시작을 허용하세요. 일부 시스템은 최근 앱 목록에서 잠금을 걸어야 하기도 합니다;
• 앱별 프록시 설정 오류: 클라이언트의 앱별 프록시(허용 / 제외 목록)에서 대상 앱이 제외되어 있으면 그 앱은 당연히 프록시를 타지 않습니다. 문제가 생기면 먼저 앱별 프록시를 기본값으로 복원한 뒤 점검하세요;
• 데이터 절약 모드와 개인 DNS: 시스템의 데이터 절약 모드는 백그라운드 인터넷 연결을 제한합니다. 시스템 차원의 "개인 DNS" 설정도 클라이언트 DNS와 충돌할 수 있으니, 점검 중에는 자동으로 설정하세요.

Android용 주력 클라이언트(Clash Plus, Clash Meta for Android, FlClash, Surfboard)는 다운로드 페이지 Android 영역에서 확인하세요. 같은 구독을 다른 클라이언트로 바꿔 교차 검증하는 방식은 휴대폰에서도 마찬가지로 유용합니다.

iOS: VPN 설정을 중심으로

• 설치 경로: iOS는 App Store에서 Clash Plus를 설치하면 되며, 입구는 다운로드 페이지 iOS 영역에 있습니다;
• VPN 설정 충돌: 여러 프록시 앱을 설치했던 기기라면 설정 → 일반 → VPN 및 기기 관리에 여러 개의 VPN 설정이 남아 있을 수 있습니다. 앱을 전환하기 전에 기존 것을 먼저 끄세요. 두 개의 설정이 통로를 다투는 것이 iOS에서 "켰는데 트래픽이 없는" 흔한 원인입니다;
• 네트워크 전환 시 짧은 단절: Wi-Fi와 셀룰러 사이를 전환할 때 VPN 터널을 다시 구축해야 하므로 몇 초간의 단절은 정상 현상입니다. 자주 끊기고 복구되지 않는다면 클라이언트의 "필요 시 연결 / 자동 재연결" 설정이 켜져 있는지 확인하세요;
• 시스템에 의한 백그라운드 회수: iOS는 메모리가 부족하면 백그라운드 앱을 회수합니다. VPN 터널은 보통 유지되지만 앱 화면은 다시 로드해야 할 수 있습니다. 앱을 다시 열면 되고 오류는 아닙니다;
• 구독 업데이트 실패: 셀룰러 네트워크에서는 시스템이 해당 앱의 셀룰러 데이터 사용을 막아두지 않았는지 확인하세요(설정 → 셀룰러에서 앱별로 스위치 확인).

모바일 공통 권장 사항

휴대폰의 네트워크 환경은 데스크톱보다 훨씬 복잡합니다. Wi-Fi, 셀룰러, 통신사 DNS, 핫스팟마다 특성이 다릅니다. "되다 안 되다" 하는 문제가 생기면 먼저 같은 네트워크 환경에서 고정해 재현하고, 지하철에서 기지국을 오가며 점검하지 마세요. 구독 업데이트가 실패하면 링크를 브라우저에 복사해 접속 가능한지 확인하세요(방법은 구독 실패 장과 동일). 링크 문제인지 앱 문제인지 빠르게 구분할 수 있습니다. 시스템의 절전 모드, 저데이터 모드는 두 플랫폼 모두에서 백그라운드 인터넷 연결을 방해하니 점검 중에는 모두 꺼두세요.