Clash 문제 해결 총정리

이 페이지는 사용 가이드와 역할이 분명히 나뉩니다. 가이드는 설치부터 첫 연결 성공까지의 기본 흐름을 다루므로 처음 설정하는 사용자에게 적합하고, 이 페이지는 "이미 설치했지만 어딘가 문제가 생긴" 상황을 위한 것으로, 증상별로 해당 장을 찾아 위에서부터 순서대로 점검 절차를 따라가면 됩니다. 각 장의 절차는 발생 빈도가 높은 순으로 배치되어 있어 앞쪽 몇 단계만으로 대부분 해결됩니다. 아직 클라이언트를 설치하지 않았다면 먼저 다운로드 페이지에서 설치 파일을 받고(전체 플랫폼 공통으로 Clash Plus를 우선 추천), 가이드를 따라 초기 설정을 마친 뒤 문제가 생기면 다시 이 페이지를 참고하세요.

1. 점검 원칙과 로그 확인법

설정을 바꾸기 전에 두 가지 습관을 들이는 것이 좋습니다. 하나는 계층별로 원인을 좁혀가는 것, 다른 하나는 한 번에 변수 하나만 바꾸는 것입니다. 프록시 경로는 위에서부터 클라이언트 UI, 코어 프로세스, 설정과 구독, 원격 노드, 로컬 시스템 환경까지 다섯 계층으로 나눌 수 있습니다. 증상이 어느 계층에서 나타나는지가 점검 방향을 결정합니다. "재설치, 구독 변경, DNS 수정"을 순서 없이 마구 시도하면 원래 단순했던 문제가 여러 문제가 겹친 상태로 악화되는 경우가 많습니다.

계층별 점검 기본 순서

• 클라이언트 계층: 화면이 정상적으로 열리는지, 토글 상태가 예상과 일치하는지, 오류 팝업이 있는지 확인합니다.
• 코어 계층: 코어 프로세스가 실행 중인지, 리스닝 포트에 접속할 수 있는지 확인합니다(2장의 curl 검증 방법 참고).
• 설정 계층: 구독이 정상적으로 불러와졌는지, 규칙 모드(Rule/Global/Direct) 중 무엇이 선택되어 있는지, 규칙이 원하는 출구로 매칭되는지 확인합니다.
• 노드 계층: 노드가 사용 가능한지, 지연 시간 테스트 결과가 어떤지, 구독이 만료되지 않았는지 확인합니다.
• 시스템 계층: 시스템 프록시/TUN이 실제로 시스템에 적용됐는지, 방화벽이나 다른 네트워크 소프트웨어의 간섭이 있는지 확인합니다.

로그 페이지와 로그 레벨

로그 페이지는 문제 해결의 주요 정보 소스입니다. 대부분의 클라이언트는 기본 레벨이 info로 되어 있어, 각 연결의 대상 도메인, 매칭된 규칙, 최종 출구를 확인할 수 있고 "이 트래픽이 실제로 어느 노드를 거쳤는가"를 파악하는 데 충분합니다. DNS나 핸드셰이크 관련 문제를 찾을 때만 임시로 debug로 전환하고, 점검이 끝나면 다시 되돌리세요. 그렇지 않으면 로그량이 늘어나 화면이 눈에 띄게 느려집니다.

최소 재현 설정

"구독 안의 복잡한 설정이 문제일 수 있다"고 의심될 때는 최소 설정으로 코어와 노드 자체가 정상인지 확인합니다. 아래 예시를 minimal.yaml로 저장하고 사용 가능한 노드 파라미터로 바꿔서 클라이언트에 로컬 설정으로 불러오세요. 최소 설정은 되는데 전체 구독은 안 된다면 문제는 구독의 규칙이나 DNS 부분에 있는 것이고, 최소 설정마저 안 된다면 문제는 노드나 시스템 계층에 있는 것입니다.

mixed-port: 7890
log-level: info
mode: rule
proxies:
  - name: test-node
    type: ss
    server: example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"
proxy-groups:
  - name: PROXY
    type: select
    proxies: [test-node]
rules:
  - MATCH,PROXY

2. 프록시를 켠 뒤 인터넷이 안 될 때

증상 정의: 클라이언트를 켠 뒤 모든 웹사이트가 열리지 않거나, 클라이언트를 종료해도 인터넷이 돌아오지 않는 경우입니다. 가장 흔하면서도 잘못 판단하기 쉬운 문제로, 핵심은 "프록시 경로 자체가 고장 난 것"과 "시스템 프록시 설정이 남아 있는 것"을 구분하는 것입니다.

1단계: 로컬 네트워크 기본 상태 확인

클라이언트를 종료한 뒤 한국 국내 사이트에 직접 접속해 보세요. 열리지 않는다면 로컬 네트워크 자체의 문제이며 프록시와는 무관하므로, 먼저 공유기나 통신사 쪽 문제를 처리해야 합니다. 열린다면 다음 단계로 넘어가세요. 클라이언트를 종료했는데도 여전히 전체 네트워크가 안 된다면 대부분 시스템 프록시 설정이 남아 있는 경우이므로, 이 장의 "시스템 프록시 잔여 설정 정리" 절로 바로 이동하세요.

2단계: 명령어로 브라우저를 거치지 않고 프록시 포트 확인

브라우저는 자체 프록시 캐시와 확장 프로그램의 간섭이 있어 테스트 도구로 적합하지 않습니다. curl로 코어 포트에 직접 요청을 보내면 깔끔하고 신뢰할 수 있는 결과를 얻을 수 있습니다:

# 코어 프록시 포트가 사용 가능한지 확인
curl -x http://127.0.0.1:7890 -I https://www.gstatic.com/generate_204

# HTTP 204 응답 → 코어와 노드 경로는 정상, 문제는 시스템 프록시 계층에 있음, 7장 참고
# connection refused → 코어가 리스닝하지 않음, 8장 참고(프로세스/포트 문제)
# 장시간 응답 없이 타임아웃 → 노드 사용 불가, 3장 참고

3단계: 규칙 모드와 출구 확인

프록시 페이지 상단의 모드 스위치를 잘못 전환해도 "전체 네트워크가 안 되는" 상황이 생길 수 있습니다. Global 모드가 이미 사용 불가능한 노드를 가리키고 있으면 모든 트래픽이 함께 실패하고, Direct 모드는 일부 네트워크 환경에서 특정 사이트에 접근할 수 없는 형태로 나타납니다. 평소에는 Rule 모드를 유지하고, 정책 그룹에서 현재 선택된 노드의 지연 시간 테스트가 초록색인지 확인하세요. 또한 구독에 MATCH,REJECT 같은 최종 차단 규칙이 의도치 않게 활성화되어 있는지 확인하세요. 로그 페이지에서 다수의 연결이 REJECT에 매칭되어 있다면 이런 규칙이 막고 있는 것입니다.

시스템 프록시 잔여 설정 정리

클라이언트가 비정상적으로 종료되면(크래시, 강제 종료) 시스템 프록시 설정을 복구할 시간이 없어, 시스템이 이미 존재하지 않는 127.0.0.1:7890으로 계속 트래픽을 보내게 됩니다. 이는 "클라이언트를 종료했더니 오히려 인터넷이 끊어지는" 형태로 나타납니다. 해결 방법: 클라이언트를 다시 켠 뒤 정상적으로 한 번 더 종료하면 대개 자동으로 복구됩니다. 안 되면 수동으로 정리하세요. Windows는 "설정 → 네트워크 및 인터넷 → 프록시"에서 "프록시 서버 사용"을 끄고, macOS는 다음 명령을 사용합니다:

networksetup -setwebproxystate "Wi-Fi" off
networksetup -setsecurewebproxystate "Wi-Fi" off

3. 모든 노드가 타임아웃되거나 지연 시간 테스트가 실패할 때

먼저 "전체 타임아웃"과 "일부 타임아웃"을 구분하세요. 두 경우의 원인은 거의 겹치지 않습니다.

모든 노드 타임아웃

1. 로컬 시간을 확인하세요. 대부분의 암호화 프로토콜은 시간 오차에 민감해서, 시스템 시간과 표준 시간의 차이가 1~2분을 넘으면 핸드셰이크가 전부 실패합니다. 시스템의 자동 시간 동기화를 켜고, 시간대를 수동으로 바꾼 경우 특히 확인하세요.
2. 구독이 만료되지 않았는지 확인하세요. 서비스 제공자는 구독이 만료되어도 노드 항목은 그대로 두고 연결만 거부하는 경우가 많아, 이는 전체 타임아웃으로 나타납니다. 제공자 관리 페이지에 로그인해 유효 기간을 확인하고, 만료됐다면 갱신 후 구독을 업데이트하세요.
3. 방화벽과 보안 소프트웨어를 확인하세요. Windows에서 코어를 처음 실행할 때 방화벽 권한 팝업을 거부했다면 아웃바운드 연결이 조용히 차단될 수 있습니다. "Windows 보안 → 방화벽 및 네트워크 보호 → 앱이 방화벽을 통과하도록 허용"에서 코어 프로세스가 허용되어 있는지 확인하세요. 타사 보안 소프트웨어도 마찬가지로 확인이 필요합니다.
4. 다른 네트워크 환경에서 교차 검증하세요. 휴대폰 테더링을 켜서 컴퓨터를 연결한 뒤 다시 테스트해 보세요. 테더링에서는 정상이고 기존 네트워크에서는 전체 타임아웃이라면, 현재 네트워크가 프록시 프로토콜을 방해하고 있는 것이며 클라이언트나 구독과는 무관합니다.

일부 노드 타임아웃

일부 노드의 타임아웃은 정상적인 현상입니다. 노드 서버 장애, 회선 불안정, 대상 네트워크의 차단 등이 원인일 수 있습니다. 처리 원칙은 간단합니다. 지연 시간이 정상인 노드로 바꿔 쓰고, 몇 시간 후나 구독을 업데이트한 뒤 다시 확인하세요. 특정 지역의 노드가 장기간 전부 죽어 있다면 서비스 제공자에게 알리세요. 클라이언트 쪽에서는 고칠 수 있는 부분이 없습니다.

지연 시간 수치를 올바르게 이해하기

지연 시간 테스트는 url-test로 지정된 테스트 주소에 한 번 요청을 보내고 시간을 측정하는 것으로, 이 수치는 "테스트 대상까지의 한 번 왕복"을 반영할 뿐 실제 브라우징 체감과 같지 않습니다. 테스트 주소 자체가 접속 불가능한 상태라면 정상인 노드도 타임아웃으로 표시됩니다. 테스트 주소는 정책 그룹에서 직접 지정할 수 있습니다:

proxy-groups:
  - name: AUTO
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    proxies: [node-a, node-b]

지연 수치와 실제 체감 사이의 차이가 어디서 오는지(테스트 대상, 패킷 손실, 대역폭 제한)는 블로그에 자세히 다룬 글이 있습니다: Clash 지연 테스트 원리 분석.

4. 구독 가져오기 및 업데이트 실패

구독 문제의 오류 메시지에는 유용한 정보가 많이 담겨 있습니다. 먼저 오류 키워드로 아래 표를 확인한 뒤, 세부 절을 참고하세요.

형식 불일치

"다른 소프트웨어에서는 링크가 정상 작동하는데 Clash에서는 가져오기 실패하거나 노드가 비어 있는" 경우는 대부분 형식 문제입니다. Clash 계열 클라이언트는 완전한 YAML 설정을 필요로 하는데, 일부 링크는 Base64로 인코딩된 순수 노드 목록만 반환합니다. 판별 방법은 링크를 브라우저에 붙여넣어 열어보는 것입니다. proxies:, rules: 같은 필드가 보이면 YAML이고, 공백 없는 긴 영숫자 문자열이 보이면 Base64입니다. 제공자 관리 페이지에는 보통 "Clash 구독" 전용 링크가 있으니 우선 그것을 사용하고, 없다면 구독 변환 도구로 Clash 형식으로 바꾼 뒤 가져오세요. 각 형식의 구조 차이와 변환 시 주의점은 블로그를 참고하세요: Clash 구독 형식 알아보기.

구독 업데이트의 네트워크 순환 문제

일부 네트워크 환경에서는 구독 서버에 직접 접속할 수 없어 업데이트 요청 자체가 프록시를 거쳐야 하는데, 프록시는 다시 구독 안의 노드에 의존합니다. 즉 닭과 달걀 문제입니다. 대부분의 클라이언트는 구독 설정에 "프록시로 업데이트" 스위치를 제공합니다. 노드가 아직 사용 가능할 때는 켜서 업데이트하고, 노드가 전부 죽었을 때는 꺼서 구독 서버에 직접 접속 가능한 네트워크(예: 휴대폰 테더링)로 전환한 뒤 한 번 업데이트하고, 노드가 복구되면 다시 전환하세요.

수동 가져오기로 마무리하기

자동 업데이트가 모두 실패해도 안정적인 대안이 있습니다. 브라우저로 구독 링크를 직접 열어 반환된 내용을 .yaml 파일로 저장한 뒤, 클라이언트 설정 페이지에서 "로컬 파일 가져오기"를 선택하세요. 이 방법은 클라이언트의 다운로드 로직을 거치지 않아 UA, 프록시 순환 등 네트워크 관련 간섭을 모두 피할 수 있으며, "링크 자체가 문제인지, 클라이언트의 다운로드 과정이 문제인지"를 검증하는 데도 자주 사용됩니다.

5. 연결은 정상인데 속도가 느릴 때

지연 시간과 대역폭을 먼저 구분하기

"느림"에는 두 가지가 있습니다. 웹페이지가 열리기 전 대기 시간이 긴 것은 지연 시간이 높은 것이고, 영상 화질이 올라가지 않거나 다운로드 속도가 낮은 것은 대역폭이 부족한 것입니다. 지연 시간이 낮다고 해서 대역폭이 크다는 뜻은 아닙니다. 지연 테스트는 작은 요청 하나만 보내므로 처리량을 측정할 수 없습니다. 두 경우의 점검 방향도 다릅니다. 지연 시간이 높으면 물리적으로 더 가까운 노드로 바꾸는 것을 우선하고, 대역폭이 낮으면 노드 배율과 로컬 회선을 먼저 점검하세요.

점검 순서

1. 노드를 바꿔가며 비교하세요. 같은 구독 안에서 지역이 다른 노드 세 개 이상을 각각 한 번씩 테스트하세요. 전부 느리다면 다음 단계로, 일부만 느리다면 해당 노드 자체의 혼잡이니 피하면 됩니다.
2. 직접 연결 대역폭을 측정해 기준값을 잡으세요. 프록시를 끄고 국내 속도 측정 사이트로 한 번 테스트하세요. 직접 연결 자체가 몇십 메가밖에 안 나온다면 프록시 속도가 이를 넘을 수 없으므로 먼저 기대치를 조정해야 합니다.
3. 로컬 점유 상태를 확인하세요. 다운로드 도구, 클라우드 동기화, 시스템 업데이트는 업로드와 다운로드 대역폭을 잠식합니다. 로그 페이지나 연결 페이지에서 트래픽 순으로 정렬해 대역폭을 많이 쓰는 프로세스를 찾아내세요.
4. 트래픽 분배가 잘못되지 않았는지 확인하세요. 규칙 설정이 잘못되면 국내 트래픽이 해외 노드를 거치게 되어 "국내 사이트도 느려지는" 현상이 나타납니다. 로그 페이지에서 국내 도메인이 DIRECT로 매칭되는지 확인하세요. 그렇지 않다면 규칙 세트 순서를 확인하세요. 보통 사용자 규칙이 GEOIP 기본 규칙을 뒤로 밀어낸 경우입니다.
5. 저녁 혼잡 시간대와 교차 검증하세요. 매일 특정 시간대에만 느리다면 회선 혼잡의 전형적인 특징이니, 인기 없는 지역의 노드로 바꾸거나 제공자에게 회선 종류를 문의하세요.

6. DNS 관련 문제

두 가지 해석 모드의 차이

Clash 계열 코어는 DNS 처리에 fake-ip와 redir-host 두 가지 강화 모드를 제공합니다. fake-ip는 198.18.0.0/16 예약 대역의 가짜 주소로 로컬 조회에 응답하고, 실제 해석은 노드 쪽에서 이루어져 매칭이 빠르고 유출이 적어 현재 주류 기본값입니다. redir-host는 로컬에서 실제 해석을 완료합니다. 원리에 대한 자세한 분석은 블로그를 참고하세요: Fake-IP 모드 원리 상세 설명. 정상적으로 동작하는 DNS 설정은 대체로 다음과 같습니다:

dns:
  enable: true
  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

전형적인 증상과 해결법

• IP로는 접속되는데 도메인으로는 안 되는 경우: DNS 해석 단계에 문제가 있습니다. 설정에서 dns.enable이 true인지, nameserver에 접속 가능한지 확인하세요. 로그를 임시로 debug로 전환하면 각 조회가 어디로 전송되고 어떤 응답을 받았는지 바로 확인할 수 있습니다.
• 어떤 프로그램이 198.18.x.x로 연결됐다고 표시되는 경우: 이는 fake-ip의 가짜 주소로, 프록시를 거치지 않는 프로그램이 이를 그대로 받은 것입니다. 해당 프로그램이 사용하는 도메인을 fake-ip-filter에 추가해 실제 주소가 반환되도록 하세요.
• 같은 네트워크의 기기(프린터, NAS, 무선 디스플레이 등)에 연결이 안 되는 경우: fake-ip가 로컬 도메인 해석을 가져간 것입니다. fake-ip-filter에 *.lan, +.local 같은 로컬 접미사가 포함되어 있는지 확인하세요. 문제 기기가 고정 호스트명을 쓴다면 그 호스트명도 함께 추가하세요.
• 네트워크 전환 후 전체 해석이 이상해지는 경우: fake-ip 캐시가 새 네트워크 환경과 맞지 않는 상태입니다. 클라이언트에서 "fake-ip 캐시 지우기"를 실행하거나(대부분 클라이언트가 설정 또는 홈 화면에 버튼을 제공) 코어를 재시작하세요.
• 온라인 게임, P2P 애플리케이션 이상: 이런 애플리케이션은 실제 IP에 민감해서 fake-ip에서 문제가 생기기 쉽습니다. 해당 도메인에 필터 예외를 추가하거나, 전체를 redir-host 모드로 바꿔 테스트해 보세요.

7. 시스템 프록시가 적용되지 않을 때

시스템 프록시의 한계

"시스템 프록시"는 운영체제에 HTTP 프록시 주소를 등록하는 것에 불과하며, 이 시스템 설정을 실제로 읽어들이는 프로그램만 프록시를 거칩니다. 브라우저와 대부분의 일반적인 데스크톱 소프트웨어는 이를 읽지만, 명령줄 도구, 일부 채팅/게임 클라이언트, 많은 백그라운드 서비스는 전혀 읽지 않습니다. 이는 오류가 아니라 메커니즘상의 한계입니다. 판단 방법: 브라우저는 프록시가 정상 작동하는데 특정 프로그램만 안 된다면, 그 프로그램이 시스템 설정을 읽지 않는 것으로 거의 확정할 수 있습니다.

명령줄 도구를 프록시로 연결하기

터미널의 git, 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:7890

Windows의 PowerShell에서는 $env:https_proxy="http://127.0.0.1:7890"로 동일하게 설정할 수 있습니다. 장기간 유지하려면 셸 설정 파일에 작성하되, 점검 단계에서는 임시 설정만 하는 것을 권장합니다. 정리를 잊으면 새로운 문제가 생길 수 있습니다.

말썽 부리는 프로그램은 TUN 모드로 처리

TUN 모드는 가상 네트워크 카드를 만들어 네트워크 계층에서 모든 TCP/UDP 트래픽을 가져가므로 프로그램의 협조 여부와 무관하게 작동하며, "특정 소프트웨어가 아무리 해도 프록시를 안 거치는" 문제를 해결하는 범용적인 방법입니다. 두 방식의 비교입니다:

시스템 프록시 스위치는 켜져 있는데 시스템에는 적용되지 않은 경우

일부 상황에서는 클라이언트에서는 켜짐으로 표시되지만 시스템 설정에는 비어 있는 경우가 있습니다. 대부분 권한 부족이나 다른 소프트웨어가 역으로 덮어쓴 것입니다. 클라이언트를 관리자 권한으로 다시 실행해 보세요. 여전히 안 된다면 보안 프로그램이나 네트워크 가속 소프트웨어가 부팅 후 프록시 설정을 다시 쓰고 있는지 확인하세요. 이런 충돌은 둘 중 하나만 선택하는 수밖에 없습니다.

8. 클라이언트 크래시와 비정상 종료

시작 즉시 종료: 먼저 설정 파싱을 확인

실행하자마자 꺼지거나 트레이 아이콘이 잠깐 나타났다가 사라진다면 먼저 설정 파일 파싱 실패를 의심하세요. YAML은 들여쓰기와 콜론 뒤 공백에 매우 민감하므로, 설정을 직접 수정한 경우 특히 다시 확인해야 합니다. 확인 방법: 클라이언트 로그 파일(보통 클라이언트 데이터 디렉터리의 logs 하위 폴더)을 찾아 마지막 몇 줄의 error 기록을 보세요. 파싱 오류라면 줄 번호가 표시됩니다. 또는 구독을 수정 전 버전으로 되돌리거나 1장의 최소 설정으로 실행해 보면, 실행되면 설정 문제라는 것을 확인할 수 있습니다.

포트 점유

코어가 시작할 때 리스닝할 포트를 다른 프로세스가 이미 점유하고 있으면(이전 코어 프로세스가 완전히 종료되지 않았거나 다른 프록시 소프트웨어가 실행 중인 경우가 흔함) 시작에 실패하거나 반복적으로 재시작됩니다. 점유 확인 방법:

# Windows
netstat -ano | findstr :7890

# macOS / Linux
lsof -i :7890

점유 중인 프로세스를 찾아 종료하거나, 클라이언트 설정에서 mixed-port를 사용하지 않는 포트(예: 7891)로 바꾼 뒤 다시 시작하세요. 포트를 바꿨다면 7장에서 7890으로 고정된 모든 부분도 함께 바꿔야 합니다.

캐시 손상과 깨끗한 재설치

실행 중 무작위로 크래시가 나거나, 화면이 흰색으로 나오거나, 설정이 바뀌지 않는다면 클라이언트 캐시를 정리해 보세요. 클라이언트를 종료하고, 데이터 디렉터리로 들어가 캐시 관련 하위 폴더(보통 이름에 cache가 포함됨)를 삭제한 뒤, profiles(구독과 설정)는 그대로 두고 다시 시작하세요. 여전히 불안정하다면 깨끗하게 재설치하세요. profiles 디렉터리를 먼저 백업하고, 제거 후 남은 데이터 디렉터리를 수동으로 삭제한 다음 다운로드 페이지에서 현재 버전을 다시 설치하고, 설치 후 백업한 구독 파일을 다시 가져오세요. 클라이언트 간 안정성과 기능 차이는 선택 가이드를 참고해 다른 클라이언트로 교차 검증할 수 있습니다.

크래시 패턴 기록 방법

간헐적인 크래시는 가장 파악하기 어렵습니다. 세 가지를 기록하는 것을 권장합니다: 크래시 전에 어떤 작업을 하고 있었는지, 그때 TUN을 켜고 있었는지, 로그 파일의 마지막 20줄입니다. 이 세 가지 정보만 있으면 스스로 점검하든 커뮤니티에 도움을 요청하든 효율이 훨씬 높아집니다.

9. 모바일 전용(Android / iOS)

Android: VPN 권한과 백그라운드 유지

Android 클라이언트(Clash Plus를 우선 추천, 대안은 다운로드 페이지 Android 영역 참고)는 시스템 VPN 인터페이스를 통해 트래픽을 가져가므로, 처음 실행할 때 "VPN 연결 생성" 시스템 팝업에 동의해야 합니다. 당시 거부했다면 "시스템 설정 → 네트워크 → VPN"에서 해당 앱의 항목을 삭제한 뒤 다시 권한을 부여하세요. 연결 아이콘(상태 표시줄의 열쇠/VPN 표시)은 있는데 트래픽이 안 간다면 클라이언트 내의 앱별 프록시 설정을 확인하세요. 블랙리스트 모드에서 제외된 앱, 화이트리스트 모드에서 선택되지 않은 앱은 프록시를 거치지 않습니다.

"쓰다가 자꾸 끊기는" 문제는 거의 항상 시스템의 절전 메커니즘이 백그라운드 프로세스를 종료하는 것입니다. 한국 및 중국 제조사 커스텀 시스템(MIUI, ColorOS, HarmonyOS 등)은 기본적으로 백그라운드 프로세스를 적극적으로 회수합니다. 세 가지 조치를 권장합니다: 클라이언트를 배터리 최적화 예외 목록에 추가(설정을 "제한 없음"으로), 멀티태스킹 화면에서 해당 앱 고정, 자동 실행 허용. 이 세 가지를 모두 설정해도 자주 끊긴다면 클라이언트의 "상시 알림" 관련 옵션을 켜서 프로세스 우선순위를 높이세요.

iOS: Network Extension의 메모리 제약

iOS 클라이언트는 App Store를 통해 배포되며, Clash Plus를 우선 추천합니다(다운로드 페이지 iOS 영역에서 스토어 링크를 바로 제공). iOS의 프록시는 Network Extension에서 동작하는데, 시스템이 이 확장 프로세스에 엄격한 메모리 상한을 두고 있습니다. 구독의 노드 수가 너무 많거나 규칙 세트가 너무 크면 확장 프로세스가 시스템에 의해 바로 종료되어 "VPN 아이콘이 1~2초 나타났다가 사라지는" 현상이나 빈번한 자동 끊김으로 나타납니다. 해결 방법: 제공자에게 간소화된 구독을 요청하거나, 변환 서비스로 쓰지 않는 지역 노드와 불필요한 규칙 세트를 잘라내 설정 크기를 줄이세요. 규칙 모드에서는 GEOIP/GEOSITE 같은 압축된 규칙을 우선 사용하고, 수만 줄에 달하는 순수 텍스트 목록은 최소화하세요.

iOS에서 흔히 나타나는 또 다른 현상: Wi-Fi와 셀룰러 네트워크를 전환한 뒤 잠시 인터넷이 안 되는 경우입니다. 이는 네트워크 전환에 따라 VPN 터널이 재구성되는 과정이므로 몇 초 기다리면 됩니다. 오래 복구되지 않으면 클라이언트에서 수동으로 한 번 재연결하세요.

모바일 네트워크와 Wi-Fi의 동작 차이

같은 휴대폰인데 Wi-Fi에서는 정상이고 셀룰러 네트워크에서는 노드가 전부 타임아웃되거나(또는 반대의 경우), 이는 두 네트워크 중 하나가 프록시 트래픽을 방해하고 있다는 뜻으로 클라이언트와는 무관합니다. 통신사 네트워크는 특정 포트나 프로토콜을 차단할 수 있고, 공개 Wi-Fi는 강제 로그인 페이지나 차단이 있을 수 있습니다. 이 차이를 활용해 교차 검증하면 문제를 "네트워크 환경" 쪽으로 빠르게 좁힐 수 있어, 앱을 재설치하는 데 시간을 낭비하지 않을 수 있습니다. 모바일 최초 설치의 전체 흐름과 권한 설정 순서는 블로그에 전체적으로 정리되어 있습니다: Clash 클라이언트 최초 설치 전체 흐름.