Clash 문제 해결 매뉴얼

인터넷 연결 안 됨: 프록시 활성화 후 전체 단절

정의: 프록시를 활성화하면 어떤 사이트에도 접속할 수 없고, 프록시를 끄면 즉시 네트워크가 복구됩니다. 이런 장애는 트래픽이 실제로 Clash에 진입했지만 올바르게 송출되지 않았다는 것을 의미합니다. 다음 순서로 진단을 진행합니다.

1.1 "전체 단절"과 "일부 불통"을 먼저 구분

세 가지 유형의 사이트를 각각 한 번씩 열어보세요: 중국 본토 사이트 하나, 해외 사이트 하나, IP 직접 접속 주소 하나(예: 라우터 관리 페이지 192.168.x.1). 세 가지 모두 불통이면 이 장의 범위에 해당합니다. 해외 사이트만 불통이면 DOC-02로 이동해 노드를 확인하고, 일부 사이트만 불통이거나 이상하게 리디렉션되면 DOC-05로 이동해 DNS와 규칙을 확인합니다. 이 단계는 10초면 되지만 이후 잘못된 방향으로 진행되는 것을 막아줍니다.

1.2 프록시 모드와 아웃바운드 선택 확인

현재 모드를 확인하세요. 규칙 모드(Rule)에서 설정 파일에 기본 규칙 MATCH가 없으면 매칭되지 않은 트래픽이 버려질 수 있습니다. 전역 모드(Global)에서 선택된 아웃바운드가 실패한 노드라면 모든 트래픽이 실패합니다. 직접 연결 모드(Direct)에서 시스템 프록시를 켜면 트래픽이 한 번 돌아 로컬을 거쳐 직접 연결되며 일반적으로 단절되지 않지만, 설정이 이상하면 루프가 발생할 수 있습니다. 처리 방법: 먼저 전역 모드로 전환해 지연 시간이 정상인 노드를 직접 선택하고 복구 여부를 확인하세요. 복구되면 문제는 규칙 또는 정책 그룹에 있으므로 규칙 모드로 돌아가 구간별로 확인합니다. 복구되지 않으면 계속 아래로 진행합니다.

1.3 로컬 리스닝 포트 확인

Clash는 기본적으로 로컬 7890 포트(혼합 포트)에서 리스닝합니다. 포트가 열려 있지 않으면 시스템 프록시가 빈 주소를 가리키게 되어 전체 단절 현상이 나타납니다. 다음 명령으로 리스닝 상태를 확인하세요:

# Windows(PowerShell 또는 CMD)
netstat -ano | findstr 7890

# macOS / Linux
lsof -i :7890

출력이 없으면 코어가 리스닝에 성공하지 못한 것입니다. 설정 파일의 mixed-port 또는 port 필드를 확인하고, 클라이언트 로그에 bind 실패 기록이 있는지 확인하세요(주로 다른 프로그램이 포트를 점유한 경우이며, DOC-07의 포트 충돌 항목으로 이동). 출력이 있지만 PID가 Clash 프로세스가 아니면 포트가 점유된 것이므로 설정에서 다른 포트로 변경하거나 점유 중인 프로세스를 종료하세요.

1.4 curl로 브라우저를 건너뛰어 경로 검증

브라우저 자체 캐시, 확장 프로그램, DoH 설정이 판단을 방해할 수 있습니다. 명령줄로 직접 로컬 프록시를 통해 내용 없는 탐지 주소를 요청하세요:

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

HTTP/2 204 또는 HTTP/1.1 204가 반환되면 "로컬 → Clash → 노드 → 목적지" 전체 경로가 정상 연결된 것이며 문제는 브라우저나 시스템 프록시 계층에 있으므로 DOC-06으로 이동하세요. 타임아웃이나 연결 재설정이 반환되면 노드 쪽이 불통이므로 DOC-02로 이동하세요.

1.5 실행 로그 확인

로그 레벨을 info 또는 debug로 조정하고 한 번 재현하며 출력을 관찰하세요. 세 가지 대표적인 기록:

• dial tcp ... i/o timeout: 노드 서버로의 연결이 타임아웃되었으며 노드에 도달할 수 없습니다. DOC-02로 이동하세요.
• EOF 또는 connection reset: 연결 성립 후 중단된 것으로, 대부분 노드 쪽 프로토콜 파라미터 불일치이거나 경로가 간섭받는 경우입니다. 노드를 변경하거나 구독 제공처에 문의하세요.
• no such rule / proxy not found: 설정 파일의 규칙이 존재하지 않는 정책 그룹 이름을 참조하고 있는 설정 오류입니다. 구독을 다시 업데이트하거나 수동으로 수정한 필드를 정정하세요.

노드 타임아웃: 지연 시간 테스트 전체 또는 부분 실패

정의: 클라이언트 노드 목록에서 지연 시간 테스트를 실행했을 때 타임아웃, -1 또는 공백으로 표시됩니다. 먼저 명확히 할 점: 지연 시간 테스트는 "해당 노드를 경유해 특정 테스트 URL에 접속하는 전체 소요 시간"을 측정하는 것이므로 테스트 실패가 반드시 노드 실패를 의미하지는 않으며, 테스트 주소 자체가 접속 불가능한 경우도 있습니다.

2.1 전체 타임아웃의 네 가지 일반적 원인

1. 구독이 만료되었거나 트래픽이 소진됨. 구독 제공처의 사용자 패널에 로그인해 계정 상태를 확인하세요. 이는 전체 타임아웃의 가장 흔한 원인이므로 먼저 확인하고 소프트웨어를 먼저 의심하지 마세요.
2. 로컬 네트워크 자체가 불통. 프록시를 끄고 임의의 본토 사이트에 직접 접속해 기본 네트워크가 정상인지 확인하세요. 기본 네트워크가 끊기면 어떤 노드도 타임아웃됩니다.
3. 테스트 URL이 로컬 네트워크에서 차단됨. 일부 클라이언트의 기본 테스트 주소는 특정 네트워크 환경에서 접속 불가능해 "노드는 실제로 사용 가능하지만 테스트가 전부 빨간색"으로 나타납니다. 테스트 주소를 https://www.gstatic.com/generate_204 또는 http://cp.cloudflare.com/generate_204로 변경한 뒤 재테스트하세요.
4. 시스템 시간 오차가 큼. 일부 암호화 프로토콜은 시간에 민감하며, 로컬 시간과 표준 시간의 차이가 일정 범위를 초과하면 핸드셰이크가 실패할 수 있습니다. 시스템 시간 자동 동기화를 켠 뒤 재테스트하세요.

2.2 부분 타임아웃: 정상 현상과 처리 기준

구독에는 보통 수십 개의 노드가 포함되어 있으며, 개별 노드가 특정 시간대에 타임아웃되는 것은 일반적인 현상으로, 노드 서버 유지보수, 회선 변동, 지역 네트워크 규제 변화 등이 원인입니다. 처리 원칙:

• 동일 지역의 여러 노드가 모두 타임아웃되고 다른 지역은 정상이면 해당 지역 회선 장애이므로 다른 지역을 사용하고 제공처의 복구를 기다리세요.
• 무작위로 산발적인 타임아웃은 처리할 필요 없이 정책 그룹에서 url-test 유형으로 자동으로 사용 가능한 노드를 선택하면 됩니다.
• 특정 노드가 장기간 고정적으로 타임아웃되면 구독 제공처에 피드백하거나 설정에서 해당 노드를 제외하세요.

2.3 정책 그룹이 실패 노드를 자동으로 회피하도록 설정

수동으로 노드를 선택하는 정책 그룹은 노드가 실패해도 자동으로 전환되지 않습니다. 자주 사용하는 정책 그룹을 자동 측정 유형으로 변경하면 "갑자기 끊긴" 느낌을 크게 줄일 수 있습니다. 예시:

proxy-groups:
  - name: "자동 선택"
    type: url-test
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 60
    proxies:
      - "노드A"
      - "노드B"
      - "노드C"

필드 설명: interval은 재테스트 간격(초)으로 120 이하로는 권장하지 않습니다. 너무 빈번한 측정은 추가 요청을 발생시킵니다. tolerance는 허용 오차(밀리초)로, 새 노드의 지연 시간이 현재 노드보다 이 값 이상 낮아야 전환됩니다. 지연 시간이 비슷한 두 노드 사이에서 계속 왔다 갔다 전환되는 것을 방지합니다.

2.4 지연 시간 수치의 올바른 해석

지연 시간 테스트는 완전한 HTTP 요청을 거치며, 수치는 노드의 물리적 거리, 프로토콜 오버헤드, 테스트 주소 위치의 세 가지 영향을 받습니다. 경험상 참고치: 아시아 근거리 노드는 수십에서 100여 밀리초, 유럽·미주 노드는 200~400밀리초가 정상 범위입니다. 지연 시간이 낮다는 것은 핸드셰이크가 빠르다는 것을 의미할 뿐 대역폭이 크다는 것을 의미하지 않습니다. 다운로드 속도 문제는 DOC-04에서 처리하세요.

구독 실패: 가져오기 오류와 업데이트 실패

정의: 구독 링크를 붙여넣어 가져오려는데 오류가 나거나, 기존 구독을 업데이트하려는데 실패합니다. 구독은 본질적으로 HTTP를 통해 가져오는 원격 설정 파일이므로, 진단 방식은 "특정 URL이 열리지 않는" 상황을 진단하는 것과 동일합니다: 먼저 링크 자체를 확인하고, 다음으로 네트워크 경로를 확인하고, 마지막으로 콘텐츠 형식을 확인합니다.

3.1 링크 자체의 유효성 확인

1. 링크의 완전성을 확인하세요. 구독 링크는 보통 길고 token 파라미터를 포함하므로, 채팅 도구에서 복사할 때 잘리거나 줄바꿈, 공백이 섞이기 쉽습니다. 제공처의 사용자 패널에서 다시 복사하는 것을 권장하며, 여러 단계를 거쳐 전달받지 마세요.
2. 링크 유형을 확인하세요. Clash 계열 클라이언트는 Clash 형식(YAML)의 구독이 필요합니다. 일부 제공처는 클라이언트마다 다른 링크를 제공하므로 형식을 잘못 가져오면 "파싱 실패"가 발생합니다. 대부분의 서비스는 링크 뒤에 파라미터를 추가해 형식을 지정할 수 있으니 제공처 안내를 참고하세요.
3. 브라우저에서 링크를 직접 열어보세요. proxies:, port: 등의 필드로 시작하는 YAML 텍스트가 보이면 링크와 콘텐츠 모두 정상이며 문제는 클라이언트 쪽에 있습니다. 404나 오류 페이지가 반환되면 링크가 만료된 것이니 제공처에 재발급을 요청하세요.

3.2 가져오기 단계 실패 처리

링크는 유효하지만 클라이언트 업데이트가 타임아웃되는 경우: 구독 서버 자체가 간섭받는 네트워크 경로에 있을 수 있습니다. 두 가지 처리 방향:

• 기존에 사용 가능한 노드로 경유해 가져오기. Clash Verge Rev 등의 클라이언트는 구독 설정에 "프록시 사용해 업데이트" 스위치를 제공합니다. 전제 조건은 현재 최소 하나의 사용 가능한 이전 설정이 있어야 합니다.
• 명령줄로 문제 재현. curl로 클라이언트 요청을 시뮬레이션해 구체적으로 어느 단계에서 실패하는지 관찰하세요:

# 직접 연결로 가져오기(링크는 본인 것으로 교체, 예시 token은 가상 값)
curl -I "https://example.com/api/v1/client/subscribe?token=xxxx"

# 로컬 프록시를 경유해 가져오기
curl -x http://127.0.0.1:7890 -I "https://example.com/api/v1/client/subscribe?token=xxxx"

직접 연결은 실패하고 프록시 경유는 성공하면 구독 서버가 직접 연결로는 접속 불가능하다는 것이므로 "프록시 사용해 업데이트"를 켜면 됩니다. 둘 다 실패하면 서버 쪽 이상이므로 기다리거나 제공처에 문의하세요.

3.3 User-Agent 제한

일부 구독 서버는 요청의 User-Agent에 따라 다른 형식을 반환하거나 낯선 UA를 거부합니다. 브라우저로는 열리지만 클라이언트가 파싱에 실패하는 경우, 클라이언트의 구독 설정에서 UA를 수동으로 clash 또는 clash.meta로 변경한 뒤 재시도하세요. 이 항목은 클라이언트 교체 후 구독이 갑자기 실패하는 상황에서 특히 자주 발생합니다.

3.4 업데이트 실패해도 이전 설정은 계속 사용 가능

클라이언트는 마지막으로 성공한 설정을 캐시하므로 구독 업데이트 실패가 계속해서 사용하는 데는 영향을 주지 않습니다. 따라서 업데이트 실패를 즉시 처리하지 않아도 되지만, 이전 설정의 노드 주소는 제공처의 순환 교체에 따라 점차 실패할 수 있으며, 사용 가능한 노드가 점점 줄어드는 형태로 나타납니다. 가능한 한 빨리 이 장의 3.1~3.3을 참고해 업데이트 기능을 복구하세요.

속도 저하: 연결은 정상이지만 대역폭이 기대에 미치지 못함

정의: 웹페이지는 열리고 동영상도 재생되지만 속도가 로컬 광랜 수준이나 이전 경험보다 확연히 낮습니다. 속도 문제는 변수가 가장 많으므로 반드시 단계별로 분리해야 합니다: 로컬 네트워크 → 노드 → 프로토콜 → 규칙 → 목적지 사이트.

4.1 기준 설정: 먼저 직접 연결, 그다음 프록시 측정

프록시를 끄고 본토 속도 측정 서버로 한 번 측정해 수치를 기록해 로컬 광랜 기준값으로 삼습니다. 프록시를 켜고 특정 노드를 선택해 같은 목적지나 노드 소재 지역의 측정 지점으로 다시 측정합니다. 프록시 속도가 기준값의 절반 이상이면 일반적으로 정상적인 손실 범위에 속합니다. 차이가 크면 계속 아래로 진단하세요.

4.2 노드 쪽 요인

• 노드 부하. 피크 시간대(저녁)에는 공용 노드 사용자가 집중되어 대역폭이 분산됩니다. 비인기 지역 노드로 바꾸거나 시간대를 피해 비교하면 차이가 확실히 드러납니다.
• 회선 유형. 동일 구독 내에서도 노드마다 지나는 국제 회선의 품질 차이가 큽니다. 자주 사용하는 3~5개 노드를 각각 실측해 각자의 안정적인 속도를 기록하고, 성능이 좋은 것을 고정으로 사용하세요. 지연 시간 수치만 보고 노드를 선택하지 마세요.
• 배율 표시. 일부 제공처는 고품질 회선에 트래픽 배율을 설정하며, 노드 이름에 표기되는 경우가 많으니 선택 시 주의하세요.

4.3 클라이언트와 프로토콜 쪽 요인

• 코어 버전. mihomo 코어는 새 프로토콜과 동시 처리 성능 최적화가 지속적으로 업데이트되므로, 오랫동안 업그레이드하지 않은 클라이언트는 성능이 저하될 수 있습니다. 설치 파일 페이지에서 현재 버전을 확인하세요. Clash Plus와 Clash Verge Rev 모두 mihomo 코어를 내장하고 있습니다.
• UDP 지원. 영상 통화, 게임, 일부 스트리밍 서비스는 UDP에 의존합니다. 노드나 설정에서 UDP를 허용하지 않으면 이런 애플리케이션이 저하되거나 끊길 수 있습니다. 설정에서 해당 프록시의 udp: true 필드와 제공처의 UDP 포워딩 지원 여부를 확인하세요.
• 브라우저 QUIC. 브라우저가 일부 사이트에 HTTP/3(UDP 443)를 사용할 때, UDP 포워딩 품질이 나쁜 노드에서는 오히려 더 느려집니다. 규칙에서 QUIC를 차단해 강제로 TCP로 되돌리는 것이 흔히 사용되는 방법입니다:

rules:
  - AND,((NETWORK,UDP),(DST-PORT,443)),REJECT

4.4 규칙 쪽 요인: 트래픽 경로가 올바른지 확인

속도가 느린 숨겨진 원인 중 하나는 "직접 연결해야 할 트래픽이 프록시를 거치는 것"입니다. 본토 사이트가 해외 노드를 돌아서 다시 돌아오면 속도가 크게 떨어집니다. 클라이언트의 연결 패널에서 현재 활성 연결을 확인해 본토 도메인이 DIRECT에 매칭되고, 해외 도메인이 프록시 정책 그룹에 매칭되는지 확인하세요. 분기 규칙 설정이 부적절한 경우, 사이트 내 문서 규칙 분기 실전 가이드를 참고해 교정하세요.

4.5 로컬 환경 요인

Wi-Fi 신호가 약함, 라우터 성능 부족, 다른 기기의 대역폭 점유 등이 모두 "노드가 느리다"고 오판될 수 있습니다. 유선 직접 연결이나 라우터에 가까운 위치에서 재측정해 로컬 간섭을 배제하세요. 소프트웨어 라우터/라우터에서 코어를 실행하는 사용자는 기기의 CPU 사용률에도 주의해야 합니다. 암호화 트래픽의 처리량은 기기 성능에 제한되므로, 저사양 기기가 100Mbps 상한에 걸리는 것은 정상적인 현상입니다.

DNS 오류: 해석 오류, 누출 및 일부 사이트 접속 불가

정의: 전체 네트워크는 사용 가능하지만 일부 사이트가 열리지 않거나 오류 페이지로 이동하거나, 검사 도구에서 DNS 누출이 표시됩니다. DNS는 Clash 장애 중 가장 직관적이지 않은 유형인데, 증상은 "특정 사이트"에 나타나지만 근본 원인은 해석 계층에 있기 때문입니다.

5.1 DNS 문제인지 판단

열리지 않는 사이트에 대해: IP 직접 연결로는 접속이 되는지(해당 사이트가 지원하는 경우), 또는 클라이언트 로그에서 해당 도메인이 해석한 IP가 명백히 이상한지(예약 주소로 해석되거나 목적지 서비스 제공사의 주소 범위에 속하지 않는 경우) 확인하면 해석 문제로 판단할 수 있습니다. 또 다른 대표적인 신호: 프록시를 켠 상태에서 특정 사이트가 "귀하의 지역에서는 이용할 수 없습니다"라고 표시하지만 노드 지역은 명백히 올바른 경우—대부분 DNS 요청이 직접 연결로 나가면서 실제 위치가 노출된 것입니다.

5.2 fake-ip와 redir-host 이해

Clash의 enhanced-mode에는 두 가지 값이 있습니다. fake-ip 모드에서는 코어가 도메인 요청에 즉시 198.18.0.0/16 대의 가짜 주소를 반환하고, 실제 해석은 아웃바운드 시점으로 지연됩니다. 장점은 응답이 빠르고 자연스럽게 오염을 방지한다는 것이며, 단점은 실제 IP에 의존하는 일부 프로그램(로컬 네트워크 탐색, 일부 게임 플랫폼)이 이상해질 수 있다는 것입니다. redir-host 모드는 실제 해석 결과를 반환해 호환성이 좋지만 상류 DNS의 품질에 더 의존합니다. 일반적으로 데스크톱과 모바일 모두 fake-ip를 권장하며, 필터 목록을 함께 사용해 로컬 네트워크 도메인을 제외합니다.

5.3 바로 적용 가능한 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://120.53.53.53/dns-query
  fallback:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN

구조 설명: nameserver는 일상적인 해석을 담당하며, 중국 본토 DoH를 넣어 본토 도메인 해석을 빠르고 정확하게 유지합니다. fallback은 오염이 의심되는 도메인의 재해석을 담당하며 해외 DoH를 넣습니다. fallback-filter는 GeoIP로 판단해, 해석 결과가 CN 주소 범위에 속하지 않으면 fallback의 결과를 사용합니다. 각 필드의 완전한 원리와 하이재킹 시나리오는 사이트 내 문서 Clash DNS 설정 상세 가이드를 참고하세요.

5.4 DNS 누출 확인 및 처리

1. 프록시를 경유해 DNS 누출 검사 사이트에 접속해 나열된 해석 서버의 소속을 확인하세요. 전부 노드 소재 지역의 서버이면 정상이고, 로컬 통신사 서버가 나타나면 누출입니다.
2. 누출 원인을 확인하세요. 흔한 원인 세 가지: 브라우저 내장 DoH(설정에서 DNS over HTTPS를 별도로 구성해 Clash를 건너뜀), 시스템 프록시 모드에서 UDP 53 요청이 프록시를 경유하지 않음, IPv6 해석 우회.
3. 항목별로 처리: 브라우저 내장 보안 DNS를 끄세요. TUN 모드를 켜서 DNS 요청도 인계받도록 하세요(DOC-06 참고). 설정에서 ipv6: false를 설정하거나 IPv6 규칙을 보완하세요.

5.5 오래된 GeoIP 데이터베이스로 인한 오판

규칙 중 GEOIP,CN,DIRECT는 로컬 GeoIP 데이터베이스에 의존합니다. 데이터베이스가 오랫동안 업데이트되지 않으면 새로 사용되는 주소 범위가 오판되어, 일부 본토 사이트가 잘못 프록시를 경유하거나 일부 해외 사이트가 잘못 직접 연결되는 현상이 나타납니다. 대부분의 클라이언트는 설정에 GeoIP/GeoSite 데이터베이스 업데이트 입구를 제공하므로 한 번 업데이트하고 코어를 재시작하면 됩니다. 업데이트가 실패하면 먼저 현재 프록시가 사용 가능한지 확인한 뒤 "프록시를 경유해 업데이트"하는 방식으로 재시도하세요.

시스템 프록시 미작동: 클라이언트는 실행 중이지만 트래픽은 직접 연결

정의: 클라이언트는 정상 실행 중이고 노드 지연 시간도 정상이지만, 브라우저나 애플리케이션의 트래픽이 프록시를 거치지 않습니다. 핵심 인식: "시스템 프록시"는 운영체제 계층의 권고성 설정일 뿐이며, 애플리케이션이 이를 따를 수도, 무시할 수도 있습니다. 이것이 이 장의 진단 틀을 결정합니다.

6.1 시스템 프록시 설정이 반영되었는지 확인

먼저 클라이언트의 "시스템 프록시" 스위치가 켜져 있는지 확인한 후, 운영체제 계층에서 확인하세요: Windows는 "설정 → 네트워크 및 인터넷 → 프록시"에서 수동 프록시가 127.0.0.1:7890을 가리키는지 확인합니다. macOS는 "시스템 설정 → 네트워크 → 세부 정보 → 프록시"에서 HTTP/HTTPS 프록시 항목을 확인합니다. 클라이언트에서는 켰지만 시스템에 반영되지 않은 경우, 흔한 원인은 권한 부족이거나 다른 프록시 소프트웨어가 설정을 선점한 것이니 클라이언트를 재시작하거나 충돌하는 소프트웨어를 종료한 뒤 재시도하세요.

6.2 시스템 프록시를 거치지 않는 트래픽 유형

6.3 명령줄 도구의 프록시 설정

# macOS / Linux(현재 터미널 세션에 적용)
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:7890

# Windows PowerShell
$env:HTTPS_PROXY="http://127.0.0.1:7890"
$env:HTTP_PROXY="http://127.0.0.1:7890"

# git 개별 설정(전역)
git config --global http.proxy http://127.0.0.1:7890

검증 방법: curl -I https://www.gstatic.com/generate_204를 실행한 뒤, 클라이언트의 연결 패널에서 curl로부터의 연결 기록이 보이면 정상 작동 중입니다.

6.4 TUN 모드로 시스템 프록시 대체

TUN 모드는 가상 네트워크 카드를 생성해 시스템 라우팅 계층에서 모든 트래픽을 인계받으므로 어떤 애플리케이션의 협조에도 의존하지 않는, "시스템 프록시를 준수하지 않는" 문제를 근본적으로 해결하는 방식입니다. 활성화 요점: 데스크톱에서는 관리자/시스템 확장 권한을 부여해야 합니다. 처음 켤 때는 서비스 구성 요소 설치가 필요합니다(클라이언트가 안내합니다). 활성화 후에는 이중 프록시를 방지하기 위해 시스템 프록시 스위치를 끄는 것을 권장합니다. 원리와 플랫폼별 단계는 사이트 내 문서 TUN 모드 원리와 활성화 단계를 참고하세요.

6.5 브라우저 확장 프로그램과 PAC의 충돌

브라우저에 SwitchyOmega 등의 프록시 확장 프로그램이 설치된 경우, 확장 프로그램의 설정이 시스템 프록시보다 우선순위가 높습니다. 시스템 프록시가 명백히 올바른데도 브라우저가 여전히 확장 프로그램의 기존 규칙을 따르는 형태로 나타납니다. 처리 방법: 확장 프로그램을 "시스템 프록시" 모드로 전환하거나, 직접 비활성화하세요. 마찬가지로, 시스템에 남아 있는 PAC 자동 설정 스크립트 주소도 수동 설정을 덮어씌울 수 있으니, 진단 시 "설정 자동 검색"과 "설정 스크립트 사용"을 함께 끄세요.

클라이언트 크래시: 시작 실패, 강제 종료 및 화면 멈춤

정의: 클라이언트가 시작되지 않거나, 시작 후 즉시 종료되거나, 코어가 반복적으로 재시작되거나, 화면이 오랫동안 응답하지 않습니다. 이런 문제의 90%는 네 가지 원인으로 귀결됩니다: 설정 구문 오류, 포트 충돌, 권한 부족, 설치 파일 손상. 발생 빈도가 높은 순서로 진단하세요.

7.1 설정 파일 구문 오류

YAML은 들여쓰기와 콜론 뒤 공백에 매우 민감하며, 설정을 직접 수정한 후 코어가 실행되지 않는 것이 가장 흔한 크래시 원인입니다. 확인 방법: 클라이언트 로그(Clash Verge Rev의 앱 로그, 각 클라이언트 설정의 로그 입구)를 확인하면 코어가 오류에 행 번호를 표시합니다. 예: yaml: line 42: mapping values are not allowed in this context. 처리: 행 번호를 따라 들여쓰기를 수정하거나, 임시로 수정하지 않은 구독 설정으로 전환해 복구되는지 확인하세요. 설정을 수정하기 전 백업을 복사해두는 것이 가장 저렴한 안전장치입니다.

7.2 포트 충돌

7890(프록시), 9090(외부 컨트롤) 등의 포트가 다른 프로그램에 점유되면 코어 시작이 즉시 실패합니다. 대표적인 충돌 원인: 완전히 종료되지 않은 다른 Clash 인스턴스, 다른 프록시 소프트웨어, 개발 디버깅 서비스. 확인 및 처리:

# Windows: 7890을 점유 중인 프로세스 PID를 찾고, PID로 프로세스 이름 조회
netstat -ano | findstr 7890
tasklist | findstr 

# macOS / Linux
lsof -i :7890

점유자를 확인한 후 해당 프로세스를 종료하거나, 설정에서 다른 포트로 변경하세요(동시에 시스템 프록시가 가리키는 주소도 업데이트). 여러 Clash 계열 클라이언트를 동시에 실행하지 말고, 더 이상 사용하지 않는 것은 제거하세요.

7.3 권한과 보안 소프트웨어

• Windows: 백신 소프트웨어가 코어 프로세스를 차단하거나 코어 파일을 삭제해 "어제까지는 됐는데 오늘 실행하면 종료되는" 현상이 나타날 수 있습니다. 클라이언트 설치 디렉터리를 화이트리스트에 추가한 후 재설치하세요. 오탐 원인과 처리 세부 사항은 Windows 설치 전체 절차와 흔한 함정을 참고하세요.
• macOS: 처음 실행 시 차단되면 "시스템 설정 → 개인 정보 보호 및 보안"에서 실행을 허용하세요. TUN 모드의 시스템 확장은 별도로 승인이 필요합니다.
• TUN 관련 크래시: TUN을 켜려면 관리자 권한이 필요하며, 서비스 구성 요소 설치가 불완전하면 켜자마자 크래시가 발생할 수 있습니다. 관리자 권한으로 서비스 구성 요소를 재설치하거나, 먼저 TUN을 끄고 시스템 프록시 모드로 클라이언트 본체가 정상인지 확인하세요.

7.4 설치 손상과 잔여 파일 충돌

업그레이드 실패, 디스크 이상 모두 프로그램 파일을 손상시킬 수 있습니다. 처리 순서: 먼저 제거하고, 잔여 디렉터리를 수동으로 정리하세요(주의: 설정과 구독은 보통 사용자 데이터 디렉터리에 저장되며 프로그램 디렉터리와 분리되어 있으므로, 프로그램 디렉터리를 정리해도 설정이 사라지지 않습니다. 완전히 초기화하려면 사용자 데이터 디렉터리도 삭제하세요). 그런 다음 설치 파일 페이지에서 다시 다운로드하여 설치하세요. 반복적으로 크래시가 발생하고 명확한 로그 단서가 없을 때는, 동일 코어의 다른 클라이언트로 교차 검증하세요. 예를 들어 Clash Verge Rev가 크래시하는데 Clash Plus는 정상이면, 문제가 클라이언트 본체에 있고 설정과 네트워크에는 없다고 판단할 수 있습니다.

모바일 전용: Android와 iOS의 플랫폼 특유 문제

모바일 클라이언트(Android의 Clash Plus, Clash Meta for Android, FlClash; iOS의 Clash Plus)는 모두 시스템 VPN 인터페이스를 통해 트래픽을 인계받으므로 장애 패턴이 데스크톱과 확연히 다르며 별도의 장으로 구성합니다.

8.1 Android: VPN 연결 불가

1. 시스템 VPN 권한을 확인하세요. 첫 실행 시 "연결 요청" 권한 창이 나타나며, 실수로 거부를 눌렀다면 시스템 설정의 VPN 관리 페이지에서 해당 앱의 VPN 설정을 삭제하고 클라이언트를 다시 시작해 권한 요청을 다시 유도하세요.
2. VPN 상호 배제를 확인하세요. Android는 동시에 하나의 앱만 VPN 채널을 점유할 수 있으므로, 다른 VPN 유형 앱(일부 보안 소프트웨어의 "네트워크 보호" 기능 포함)이 실행 중이면 Clash가 연결을 만들 수 없습니다. 충돌하는 앱을 비활성화한 후 재시도하세요.
3. 일부 커스텀 시스템(직장 프로필, 어린이 모드)은 VPN 권한을 제한하므로, 해당 관리 입구에서 허용해야 합니다.

8.2 Android: 백그라운드 종료와 끊김

중국산 커스텀 시스템의 적극적인 절전 전략이 모바일 끊김의 주요 원인이며, 화면 잠금 후 일정 시간이 지나면 네트워크가 끊기고 알림창 아이콘이 사라지는 형태로 나타납니다. 처리 목록:

• 시스템 배터리 설정에서 클라이언트를 "제한 없음"/"최적화 안 함"으로 설정하세요.
• 멀티태스킹 화면에서 클라이언트를 잠금(카드를 아래로 당겨 잠금)해 일괄 정리로 인한 오탐 종료를 방지하세요.
• 클라이언트의 포그라운드 서비스 상시 알림을 켜두세요. 깔끔함을 위해 끄지 마세요—상시 알림은 시스템이 프로세스 중요도를 판단하는 근거 중 하나입니다.
• 일부 시스템은 추가로 "자동 시작"과 "백그라운드에서 화면 팝업" 권한을 별도로 허용해야 합니다.

8.3 Android: 앱별 프록시

클라이언트 설정의 "앱별 프록시"(Per-App Proxy)는 어떤 앱이 VPN을 경유할지 지정할 수 있습니다. 두 가지 모드: 화이트리스트(목록 내 앱만 프록시 경유)와 블랙리스트(목록 내 앱은 우회). 뱅킹 앱이 VPN에 민감한 경우 우회 목록에 추가하면 위험 감지 오류를 해결할 수 있습니다. 반대로 특정 앱이 계속 직접 연결되는 것을 발견하면, 먼저 우회 목록에 포함되어 있는지 확인하세요. 앱별 설정을 변경한 후에는 VPN을 재시작해야 적용됩니다.

8.4 iOS: Clash Plus 사용 요점

iOS에서는 App Store를 통해 Clash Plus를 설치하며, 시스템 Network Extension 프레임워크를 기반으로 동작합니다. 플랫폼 특유의 주의사항:

• 첫 실행 시 시스템 팝업에서 VPN 설정 추가를 허용해야 하며, 거부한 경우 "설정 → 일반 → VPN 및 기기 관리"에서 처리하세요.
• 시스템의 Network Extension 메모리 할당량은 일반 앱보다 훨씬 낮으므로, 규칙 세트가 지나치게 크거나 노드가 너무 많은 설정은 확장 프로세스가 시스템에 의해 회수되는 것을 유발할 수 있으며 VPN 아이콘 순간 끊김으로 나타납니다. 구독 규모를 줄이고 초대형 규칙 세트를 로드하지 않으면 완화됩니다.
• iOS의 VPN도 동일하게 전역 상호 배제이므로 프록시 앱을 전환하기 전에 다른 앱의 연결을 먼저 끊으세요.
• Wi-Fi와 셀룰러 네트워크 전환 시 짧은 끊김이 발생하는 것은 시스템 네트워크 스택 전환의 정상 현상으로 수 초 내 자동 복구됩니다. 장시간 복구되지 않으면 연결을 한 번 껐다가 켜세요.

8.5 모바일 구독 업데이트 실패

모바일에서 구독 업데이트 시 오류가 나는 진단은 DOC-03과 동일하며, 모바일 특유의 요인 두 가지를 추가로 설명합니다: 셀룰러 네트워크에서는 일부 통신사가 낯선 도메인의 해석과 연결 정책을 더 엄격하게 적용하므로 Wi-Fi로 전환해 재시도하면 구분할 수 있습니다. 절전 모드는 백그라운드 네트워크 요청을 제한하며 포그라운드 수동 업데이트에는 영향이 없지만, "구독 자동 업데이트" 작업이 오랫동안 실행되지 않아 노드가 조용히 만료되는 경우가 있습니다. 노드가 대량으로 실패한 것을 발견하면 먼저 구독을 수동으로 한 번 업데이트한 뒤 테스트하세요.

END OF FILE / C-007

위 8개 장을 따라도 해결되지 않는 문제는 세 가지 정보를 준비해 문의하는 것을 권장합니다: 클라이언트 이름과 플랫폼, 재현 단계, 핵심 로그 조각(구독 링크와 token은 가려서). 단편적이고 빈번한 질답은 FAQ에서, 처음부터 설정하려면 설정 가이드로 돌아가고, 클라이언트를 교체하거나 업그레이드하려면 설치 파일 페이지로 이동하세요. 전 플랫폼에서 Clash Plus를 우선 추천합니다.