Clash 화면에 “연결됨”이 표시되거나 노드 옆에 지연 시간이 나타나고 로그가 계속 출력된다고 해서 브라우저 트래픽이 프록시를 통해 정상적으로 전달된다는 뜻은 아닙니다. 클라이언트가 설정을 불러오고 지연 시간을 측정했거나 코어를 시작했을 뿐일 수 있습니다. 실제 웹 접속에는 애플리케이션, 시스템 프록시 또는 TUN, Clash 수신 포트, 규칙 매칭, 정책 그룹, 프록시 노드, DNS, 대상 웹사이트로 이어지는 전체 경로가 필요합니다. 어느 한 단계라도 끊기면 겉으로는 “연결은 정상인데 웹페이지가 열리지 않는” 문제로 보일 수 있습니다.

“인터넷이 안 된다”는 문제가 어느 계층에서 발생하는지 먼저 구분하세요

처음부터 노드를 더 많이 바꾸기보다 장애 범위를 확인하는 것이 우선입니다. 자주 사용하는 웹사이트 외에 로컬 네트워크 주소, 일반 도메인, 순수 IP 연결도 각각 테스트하세요. 특정 웹사이트 하나만 실패한다면 대상 사이트의 제한, 규칙 매칭 또는 노드의 출구 문제일 수 있습니다. 모든 도메인이 실패하지만 IP 접속은 된다면 DNS를 먼저 확인하세요. 브라우저는 되지만 터미널, 게임 또는 스토어가 되지 않는다면 해당 애플리케이션이 시스템 프록시를 따르지 않는 경우가 많으므로 앱에서 프록시를 별도로 설정하거나 TUN을 사용해야 합니다.

  1. 로컬 네트워크 확인: Clash를 완전히 종료하거나 시스템 프록시를 끈 뒤, 직접 연결 웹사이트가 정상적으로 열리는지 확인하세요. 기본 네트워크 자체가 끊긴 상태라면 프록시를 계속 조정해도 소용이 없습니다.
  2. 애플리케이션별 비교: 브라우저, 명령줄, 시스템 프록시를 사용하지 않는 애플리케이션을 각각 테스트하세요. 결과의 차이를 통해 문제가 앱 프록시에 있는지 전체 전달 계층에 있는지 판단할 수 있습니다.
  3. 연결 로그 확인: 웹사이트에 접속하면서 로그에 해당 도메인, 매칭된 규칙, 최종 정책이 표시되는지 확인하세요. 새 기록이 전혀 없다면 트래픽이 Clash에 들어오지 않았을 가능성이 큽니다.
  4. 시간 초과와 주소 해석 오류 구분: “서버 주소를 찾을 수 없음”은 DNS 장애에 가깝고, “연결 거부”는 로컬 포트 오류에서 흔히 발생합니다. 오랫동안 시간 초과가 발생한다면 정책, 노드, 라우팅을 계속 확인해야 합니다.

로그는 전체 문제 해결 과정에서 가장 직접적인 근거입니다. 정상적인 요청이라면 대상 도메인이나 IP, 규칙 유형, 정책 그룹, 실제 노드를 확인할 수 있습니다. 로그에 DIRECT가 표시되면 규칙에 따라 직접 연결된 것입니다. 특정 프록시 노드가 표시된 뒤 시간 초과가 발생한다면 트래픽은 이미 코어에 들어온 상태이므로 시스템 프록시 스위치보다 노드 상태, 정책 그룹, 원격 네트워크를 우선 확인해야 합니다.

구독, 설정 파일, 정책 선택 확인

구독 업데이트가 성공했다는 것은 클라이언트가 내용을 다운로드했다는 뜻일 뿐, 현재 활성화된 설정이 방금 업데이트한 파일이라는 의미는 아닙니다. 일부 클라이언트는 여러 로컬 설정을 저장할 수 있으며 업데이트와 설정 전환은 별도로 동작합니다. 먼저 설정 화면에서 현재 설정 이름, 업데이트 시간, 활성화 상태를 확인하세요. 업데이트 후 클라이언트가 다시 불러오기를 요구한다면 로딩이 끝난 뒤 테스트해야 합니다.

코어가 설정을 완전히 불러오는지 확인

설정 파일에는 포트, DNS, 규칙, 정책 그룹, 노드 정의가 포함됩니다. YAML 들여쓰기 오류, 존재하지 않는 노드를 참조하는 정책 그룹, 규칙 제공자 다운로드 실패는 로딩 실패나 일부 기능 이상을 일으킬 수 있습니다. 구독 화면의 “업데이트 완료”만 보지 말고 코어 시작 로그를 먼저 확인하세요. 파싱 오류가 나타나면 정상적으로 시작되는 마지막 설정으로 돌아간 뒤 사용자 지정 내용을 부분별로 다시 적용하세요.

원격 규칙 집합을 사용할 때는 규칙 파일이 실제로 다운로드되었는지도 확인해야 합니다. 설정을 처음 불러오거나 네트워크 환경이 바뀌었거나 규칙 제공자 주소에 일시적으로 접근할 수 없으면 정책 그룹은 존재해도 필요한 규칙 데이터가 아직 준비되지 않을 수 있습니다. 이때는 설정을 다시 불러오고 규칙 다운로드 기록을 확인하세요. 출처가 불분명한 설정에 대량의 오버라이드 항목을 바로 추가하지 마세요. 구독 문제와 로컬 수정 사항이 뒤섞일 수 있습니다.

프록시 모드와 정책 그룹 확인

일반적인 모드에는 규칙 모드, 전역 모드, 직접 연결 모드가 있습니다. 규칙 모드는 설정의 규칙을 위에서부터 순서대로 매칭하고, 전역 모드는 보통 지정된 전역 정책으로 요청을 전달하며, 직접 연결 모드는 프록시를 우회합니다. 클라이언트가 직접 연결 모드에 머물러 있다면 노드 지연 시간이 측정되더라도 웹페이지 트래픽은 노드를 거치지 않습니다.

  • 규칙 모드: 일상적인 사용에 적합합니다. 대상 요청이 최종적으로 어떤 규칙에 매칭되었고 해당 규칙이 어느 정책 그룹을 가리키는지 확인하세요.
  • 전역 모드: 규칙 오류 여부를 짧게 확인할 때 적합합니다. 전역 모드에서는 접속되지만 규칙 모드에서는 접속되지 않는다면 규칙 순서, 정책 그룹 참조, 기본 규칙을 중점적으로 확인하세요.
  • 직접 연결 모드: 프록시를 잠시 우회할 때 사용합니다. 문제 해결이 끝나면 필요한 모드로 다시 전환하세요.

정책 그룹 이름이 같다고 해서 그룹 내부의 선택이 올바른 것은 아닙니다. 수동 선택 그룹이 이미 사용할 수 없는 노드에 머물러 있을 수 있고, 자동 속도 측정 그룹도 현재 네트워크에 적합하지 않은 측정 결과를 사용했을 수 있습니다. 정책 그룹에서 최근에 정상 작동한 노드를 명확히 선택한 뒤 실제 웹페이지 요청을 보내세요. 지연 시간 테스트는 당시 측정 주소가 응답했다는 뜻일 뿐이며, 실제 TCP, TLS, 대상 웹사이트 접속 테스트를 대신할 수 없습니다.

시스템 프록시, 수신 주소, 포트 충돌 확인

TUN을 사용하지 않을 때 브라우저와 대부분의 데스크톱 소프트웨어는 시스템 프록시를 통해 요청을 Clash로 보냅니다. 클라이언트의 “시스템 프록시” 스위치는 코어가 실제로 수신 중인 HTTP, SOCKS 또는 혼합 포트와 일치해야 합니다. 코어 재시작 실패, 포트 점유, 시스템 설정에 남은 이전 포트 때문에 프록시가 켜져 있어도 모든 요청이 로컬에서 거부될 수 있습니다.

요청이 코어에 들어오는지 먼저 확인

로그 창을 열어 둔 상태에서 웹페이지를 새로고침하세요. 로그에 새 요청이 없다면 시스템 프록시가 켜져 있는지, 프록시 서버가 로컬 주소인지, 포트가 현재 설정과 일치하는지 차례로 확인하세요. 흔히 사용하는 로컬 주소는 127.0.0.1이며, 정확한 포트는 클라이언트에 현재 표시된 값이나 설정 파일의 mixed-port, port, socks-port를 기준으로 해야 합니다. 다른 기기의 포트를 그대로 사용하지 마세요.

명령줄에서 HTTP 프록시를 명시해 테스트할 수도 있습니다. 아래 포트는 예시일 뿐이므로 실행 전에 클라이언트가 실제로 수신 중인 포트로 바꾸세요:

curl.exe -I -x http://127.0.0.1:7890 https://example.com/

프록시를 명시한 요청은 성공하지만 브라우저에서 계속 실패한다면 코어, 노드, 기본 외부 연결은 대체로 정상입니다. 시스템 프록시가 적용되지 않았거나, 브라우저에 별도 프록시가 설정되었거나, 확장 프로그램이 네트워크 설정을 변경했거나, 애플리케이션이 시스템 프록시를 읽지 않는 경우일 가능성이 큽니다. 명령이 127.0.0.1에 연결할 수 없다고 바로 표시되면 코어 실행 여부와 포트 수신 상태를 확인하세요. 요청이 로그에 들어온 뒤 원격 연결이 시간 초과되면 정책과 노드 계층으로 돌아가 처리하세요.

포트 점유와 중복 실행 확인

한 기기에서 두 개의 프록시 클라이언트를 동시에 실행하거나 이전 Clash 프로세스가 종료되지 않으면 같은 포트를 차지할 수 있습니다. 새 클라이언트 화면은 열려 있어도 코어가 실제로 포트를 수신하지 못할 수 있습니다. 시작 로그에서 address already in use, bind 또는 수신 실패 메시지를 확인하고 중복 프로세스를 종료한 뒤 코어를 다시 시작하세요. 포트를 변경해 충돌을 피할 수도 있지만 시스템 프록시도 새 포트로 함께 변경해야 합니다.

LAN 공유 옵션과 로컬 사용은 같은 의미가 아닙니다. 같은 기기에서만 접속한다면 127.0.0.1로 수신하는 것만으로 대개 충분합니다. 다른 기기가 연결해야 할 때만 LAN 접근 허용을 고려하고 시스템 방화벽과 함께 설정하세요. 로컬 브라우저 문제를 해결하려고 무작정 LAN 수신을 열지 마세요.

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

클라이언트가 비정상적으로 종료되면 운영체제에 이전 포트를 가리키는 프록시 설정이 남아 Clash를 종료한 뒤에도 브라우저가 접속하지 못할 수 있습니다. 클라이언트를 다시 시작한 뒤 먼저 “시스템 프록시”를 끄고, 운영체제의 프록시 설정 화면에서 수동 프록시가 삭제되었는지 확인한 다음 필요할 때 다시 켜세요. 기업 네트워크, 자동 구성 스크립트, 브라우저 정책이 수동 설정을 덮어쓸 수도 있으므로 시스템 네트워크 설정에서 최종 적용값을 확인해야 합니다.

DNS 실패: 도메인만 열리지 않을 뿐 네트워크가 끊긴 것은 아닐 수 있습니다

DNS는 도메인 이름을 주소로 변환합니다. Clash 또는 mihomo가 DNS를 가로채 규칙, Fake IP, 실제 주소 결과에 따라 다음 연결을 결정할 수 있습니다. DNS 설정이 작동하지 않으면 노드 지연 시간이 확인되고 프록시 포트도 정상이어도 브라우저에 도메인 해석 실패가 계속 표시될 수 있습니다. 따라서 요청이 코어에 들어온 것을 확인한 뒤 DNS를 별도로 점검해야 합니다.

증상으로 DNS 문제 판단

  • 도메인 접속은 실패하지만 기존 연결이나 IP를 직접 사용하는 일부 서비스는 계속 작동합니다.
  • 로그에 DNS 시간 초과, 업스트림 서버 접근 불가, 해석 루프 또는 쿼리 거부가 표시됩니다.
  • 네트워크를 바꾼 뒤 갑자기 작동하지 않습니다. 특히 회사 네트워크, 학교 네트워크, 공용 Wi-Fi, 가정용 네트워크 사이를 전환할 때 자주 발생합니다.
  • TUN을 끄거나 Clash DNS를 끈 뒤 복구된다면 DNS 가로채기 경로와 관련된 장애입니다.

시스템 명령으로 운영체제가 현재 도메인을 해석할 수 있는지 확인할 수 있습니다:

nslookup example.com

nslookup 결과만으로 Clash DNS가 완전히 정상이라고 단정할 수는 없습니다. 일부 애플리케이션은 브라우저 내장 보안 DNS를 사용하고, TUN은 일반 DNS 요청을 가로챌 수도 있습니다. 클라이언트 DNS 로그와 브라우저 설정을 함께 확인하세요. 브라우저에서 독립적인 암호화 DNS를 사용하면 시스템 해석 경로를 우회하거나 규칙의 예상과 다르게 동작할 수 있습니다. 문제를 확인하는 동안에는 시스템 DNS를 사용하도록 잠시 되돌린 뒤 범위를 좁히고 최종 구성을 결정하세요.

Fake IP와 redir-host 이해하기

지원되는 Clash Meta（mihomo）설정에서 fake-ip 모드는 도메인에 예약 주소를 반환하고 연결이 시작될 때 도메인을 다시 복원합니다. 이를 통해 규칙 매칭과 투명 프록시의 일관성을 높일 수 있습니다. 예약 주소가 보인다고 반드시 이상이 있는 것은 아닙니다. 실제 문제는 대개 DNS 트래픽이 올바르게 가로채지지 않았거나, Fake IP 매핑이 사라졌거나, 일부 LAN 및 특수 애플리케이션과 호환되지 않는 경우입니다.

redir-host는 실제 해석 주소를 반환하므로 호환 경로가 다르지만 모든 상황에서 더 안정적이라는 뜻은 아닙니다. Fake IP가 보인다는 이유만으로 모드를 바꾸지 마세요. 프린터, LAN 장치, 게임 플랫폼, 특정 애플리케이션만 실패한다면 먼저 fake-ip-filter에서 해당 도메인을 제외해야 하는지 확인하고, LAN 도메인이 적절한 이름 서버를 통해 해석되는지 점검하세요.

DNS 업스트림과 순환 의존성 확인

DNS 업스트림은 현재 네트워크 환경에서 접근할 수 있어야 합니다. 업스트림 자체가 프록시를 필요로 하고 프록시 연결에는 먼저 노드 도메인 해석이 필요하다면 의존성 순환이 발생할 수 있습니다. 설정의 기본 이름 서버는 보통 프록시 노드 도메인 해석에 사용되므로 시작 단계에서 직접 접근할 수 있는 해석 서비스를 선택해야 합니다. 구독 노드가 도메인 이름을 사용하는 경우 특히 중요합니다.

DNS를 변경한 뒤에는 설정을 다시 불러오고 운영체제 또는 브라우저 캐시를 삭제한 다음 재테스트하세요. 출처가 불분명한 업스트림 주소를 한 번에 여러 개 추가하지 마세요. 주소 수를 늘려도 라우팅 오류는 해결되지 않으며 오히려 시간 초과 원인을 찾기 어려워집니다. 필드 의미와 설정 관계는 사용 안내서에서 더 자세히 확인할 수 있습니다.

TUN 모드가 켜져 있는데도 접속할 수 없을 때

TUN은 가상 네트워크 인터페이스를 통해 더 많은 트래픽을 가로채므로 시스템 프록시를 따르지 않는 애플리케이션에 적합합니다. 가상 네트워크 카드, 라우팅 테이블, DNS 가로채기, 시스템 권한, 방화벽이 관련되어 일반 시스템 프록시보다 장애 지점이 많습니다. 스위치가 켜졌다고 가상 인터페이스가 성공적으로 생성된 것은 아니며 코어 로그와 시스템 네트워크 인터페이스 상태를 기준으로 확인해야 합니다.

권한과 드라이버 상태 확인

Windows에서 가상 인터페이스를 만들고 조정하려면 충분한 시스템 권한이 필요한 경우가 많습니다. macOS에서는 네트워크 확장 승인이나 관리자 인증이 필요할 수 있고, Linux에서는 TUN 장치와 적절한 네트워크 관리 권한이 필요합니다. 로그에 인터페이스 생성 실패, 라우팅 설정 실패, 권한 부족이 나타나면 노드를 계속 바꾸기보다 먼저 권한 문제를 해결하세요.

시스템 절전, 업그레이드, 네트워크 어댑터 변경 후에는 이전 가상 인터페이스나 라우팅이 제대로 해제되지 않을 수 있습니다. 먼저 TUN을 끄고 라우팅이 복구될 때까지 기다린 뒤 다시 켜세요. 그래도 실패하면 클라이언트를 완전히 종료하고 시스템을 재부팅하는 편이 스위치를 연속해서 누르는 것보다 잔여 상태를 정리하기 쉽습니다. 재부팅 후에는 시스템 프록시만 켜서 코어와 노드를 먼저 검증한 다음 TUN을 켜세요. 이를 통해 장애가 투명한 트래픽 가로채기에서 발생했는지 판단할 수 있습니다.

라우팅, 제외 항목, 순환 경로 확인

TUN에서는 Clash 자체의 연결이 다시 TUN으로 들어가 트래픽 루프가 발생하지 않도록 해야 합니다. 일반적으로 안정적인 클라이언트는 코어 프로세스와 필요한 라우팅을 자동으로 처리하지만, 사용자 지정 라우팅, 타사 방화벽, VPN, 가상 머신 소프트웨어, 기타 네트워크 필터 도구가 결과를 바꿀 수 있습니다. 문제를 확인할 때는 다른 VPN이나 프록시 도구를 잠시 중지하고 네트워크를 가로채는 프로그램 하나만 남기세요.

TUN을 켠 뒤 인터넷은 복구되지만 LAN 장치에 접근할 수 없다면 사설 네트워크 대역이 필요한 경우 직접 연결되도록 설정되어 있는지, 자동 라우팅과 엄격한 라우팅 설정이 현재 시스템에 맞는지 확인하세요. 반대로 LAN은 정상인데 인터넷 전체가 시간 초과된다면 기본 경로가 올바르게 기록되었는지, Wi-Fi와 유선 네트워크 전환에 따라 외부 연결 인터페이스가 바뀌는지 확인하세요. 모든 사설 주소를 무조건 프록시로 보내면 라우터 관리 페이지, 파일 공유, 로컬 DNS에 영향을 줄 수 있습니다.

시스템 프록시와 TUN을 무분별하게 함께 사용하지 않기

일부 클라이언트는 시스템 프록시와 TUN을 동시에 켤 수 있으며 정상적인 설정에서는 작동합니다. 하지만 문제 해결 중에는 요청이 어느 경로를 사용하는지 판단하기 어려워집니다. 먼저 TUN을 끄고 시스템 프록시만 사용해 브라우저를 테스트하세요. 정상 작동을 확인한 뒤 시스템 프록시를 끄거나 클라이언트 권장 설정을 유지한 상태에서 TUN이 터미널과 다른 애플리케이션을 제대로 가로채는지 별도로 테스트하세요. 각 단계마다 로그를 확인하고 웹페이지가 우연히 한 번 열린 것만으로 결론 내리지 마세요.

애플리케이션과 운영체제별 차이 추가 확인

같은 기기에서 일부 프로그램만 실패한다면 전체 구독 설정을 계속 바꿀 필요가 없습니다. 브라우저는 별도 프록시나 보안 DNS를 사용할 수 있고, 터미널 도구는 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY 환경 변수를 읽을 수 있으며, 게임과 스토어 앱은 시스템 프록시를 완전히 우회할 수 있습니다. 먼저 해당 애플리케이션이 어떤 네트워크 경로를 사용하는지 확인한 뒤 앱 내 프록시, 시스템 프록시, TUN 중 적절한 방식을 선택하세요.

Windows

“설정”의 수동 프록시가 클라이언트와 일치하는지 확인하고 오래된 자동 구성 스크립트도 살펴보세요. 일부 애플리케이션의 네트워크 격리나 루프백 제한 때문에 데스크톱 브라우저는 정상인데 스토어 앱만 이상할 수 있습니다. 방화벽이 코어 프로그램의 수신 또는 외부 연결을 차단할 수도 있습니다. 클라이언트 실행 파일 경로를 바꿨다면 시스템 방화벽 허용을 다시 확인하고, 클라이언트 로그에서 해당 애플리케이션의 요청이 발생하는지 검증하세요.

macOS

시스템 프록시는 네트워크 서비스별로 저장됩니다. Wi-Fi와 유선 네트워크를 전환하면 프록시가 이전 서비스에만 설정되어 있을 수 있습니다. 현재 사용 중인 네트워크 서비스에서 웹 프록시와 보안 웹 프록시를 확인하세요. TUN 또는 강화 모드를 사용하려면 네트워크 확장도 정상적으로 활성화되어야 합니다. 시스템 업데이트 후 확장 권한이 초기화되었다면 클라이언트 안내에 따라 다시 승인하세요.

Linux

데스크톱 환경의 시스템 프록시가 터미널 프로그램에 영향을 주지 않을 수 있고, 터미널 환경 변수가 그래픽 애플리케이션에 영향을 주지 않을 수도 있습니다. 적용 범위를 명확히 한 뒤 각각 테스트하세요. TUN을 사용할 때는 /dev/net/tun, 라우팅 테이블, 정책 라우팅, DNS 관리 서비스를 확인해 NetworkManager, systemd-resolved, 수동으로 기록한 DNS 설정이 서로 덮어쓰지 않도록 하세요.

Android 및 iOS

모바일 기기는 보통 시스템 VPN 인터페이스를 통해 트래픽을 가로챕니다. 상태 표시줄에 VPN이 표시되는데도 요청이 실패한다면 시스템이 클라이언트의 백그라운드 실행을 제한하는지, 다른 VPN이 동시에 켜져 있는지, 현재 Wi-Fi에서 먼저 포털 인증을 완료해야 하는지 확인하세요. 모바일 데이터와 Wi-Fi를 전환하면 특정 접속 네트워크에서만 문제가 발생하는지 빠르게 판단할 수 있습니다. 앱별 분할 라우팅이나 LAN 우회 설정도 실제 결과를 바꿀 수 있습니다.

최소한의 변경으로 접속을 복구하는 순서

아래 순서는 장애 지점을 바깥쪽부터 안쪽으로 나누어 확인하는 방식이며, “어제까지 잘 됐는데 오늘 갑자기 아무것도 열리지 않는” 상황에 적합합니다. 한 단계를 마치면 즉시 테스트하고 로그 변화를 기록하세요. 복구되었다면 이후 단계를 계속 진행하지 말고 마지막으로 변경한 항목을 다시 확인하세요.

  1. 시스템 프록시와 TUN을 끄고 기기의 기본 네트워크 및 로컬 직접 연결이 정상인지 확인합니다.
  2. Clash 코어를 시작하고 설정이 정상적으로 로드되었는지, YAML, 규칙 제공자, 수신 포트, 권한 오류가 없는지 확인합니다.
  3. 현재 활성화된 구독 설정을 확인하고 업데이트 후 다시 불러온 다음 검증 가능한 노드를 명확히 선택합니다.
  4. 직접 연결 모드가 아닌지 확인하고, 규칙이 원인인지 판단하기 위해 잠시 전역 모드를 사용합니다.
  5. 시스템 프록시만 켜고 웹페이지를 새로고침하면서 로그를 확인합니다. 로그가 없으면 시스템 프록시를 확인하고, 로그가 있으면 규칙, 노드, DNS를 확인합니다.
  6. 프록시를 명시한 명령으로 로컬 수신 포트를 테스트해 브라우저 확장 프로그램과 애플리케이션 설정의 영향을 배제합니다.
  7. 포트 점유, 중복 코어 프로세스, 시스템에 남아 있는 이전 프록시 주소를 확인합니다.
  8. 해석 오류와 DNS 로그를 바탕으로 업스트림, 브라우저 보안 DNS, Fake IP, 노드 도메인 해석을 확인합니다.
  9. 시스템 프록시가 안정적으로 작동한 뒤 TUN을 켜고 권한, 가상 인터페이스, 라우팅, 다른 VPN과의 충돌을 확인합니다.
  10. 규칙 모드와 일상 설정을 복원한 뒤 브라우저, 터미널, 대상 애플리케이션을 각각 검증합니다.

전역 모드에서 모든 노드가 시간 초과되지만 기본 네트워크가 정상이라면 다른 네트워크에서 같은 설정을 다시 테스트해 로컬 네트워크 제한과 구독 노드 장애를 구분하세요. 특정 노드 하나만 실패한다면 해당 노드를 바꾸고 로그를 보관하세요. 설정 전체를 불러오지 못한다면 설정 제공자에게 구독 상태와 형식을 확인해야 합니다. 문의할 때 운영체제, 클라이언트 버전, 코어 유형, 프록시 모드, DNS 모드, 정리된 오류 로그를 함께 제공하면 단순히 “연결되지 않는다”고 설명하는 것보다 정확한 판단을 받기 쉽습니다.

대부분의 “Clash 연결됨에도 인터넷이 되지 않음” 문제는 단일 스위치 하나로 해결되지 않습니다. 신뢰할 수 있는 해결 순서는 기본 네트워크를 확인하고, 설정과 노드를 검증한 뒤, 트래픽이 로컬 포트로 들어오는지 확인하고, 마지막으로 DNS와 TUN을 점검하는 것입니다. 설치와 권한 설정을 처음부터 다시 확인해야 한다면 전체 튜토리얼을 단계별로 따라 기존 설정에 변경 사항을 계속 덧붙이지 않도록 하세요.