Clash 연결 성공했지만 인터넷 안 됨: 순서대로 점검하는 9가지 체크리스트

왜 "연결 성공"이 "인터넷 사용 가능"과 같지 않은가

클라이언트 화면의 초록색 점이나 "연결됨" 표시는 대개 Clash와 프록시 서버 사이에 핸드셰이크 테스트가 완료되었거나, 현재 선택된 노드의 지연 테스트에 값이 반환되었다는 것만을 의미합니다. 이 상태는 "브라우저가 웹페이지를 정상적으로 불러올 수 있는가"와는 별개의 문제입니다——그 사이에는 시스템 프록시가 실제로 적용되었는지, DNS 해석이 정확한지, 규칙이 트래픽을 잘못된 출구로 보내고 있는지 등 여러 단계가 존재합니다. 어느 한 단계에서라도 문제가 생기면 "연결은 성공했지만 인터넷은 안 되는" 현상이 나타나며, 이런 단계들의 오류 정보는 보통 메인 화면에 직접 표시되지 않아 하나씩 점검해야 원인을 파악할 수 있습니다.

아래 9가지 체크포인트는 "먼저 로컬 설정을 확인하고, 다음으로 노드 자체를 검증하고, 마지막으로 규칙과 원격 서버를 점검"하는 순서로 배열되어 있습니다. 순서대로 진행하는 것을 권장합니다——건너뛰며 시도하지 마세요. 많은 경우 문제는 첫 단계에 있는데도 노드 장애로 잘못 판단되는 경우가 많습니다.

체크포인트 1~3: 먼저 로컬과 클라이언트 설정을 확인

1. 시스템 프록시가 실제로 켜져 있는가

이는 가장 쉽게 간과되는 단계입니다. 일부 클라이언트는 설정 파일을 전환하거나 재시작한 후 시스템 프록시 스위치가 꺼진 상태로 초기화되지만, 노드 연결 상태는 여전히 정상으로 표시되어 "연결된 것처럼 보이지만 사실 트래픽이 전혀 프록시를 거치지 않는" 착시를 만듭니다.

• 확인 방법: 시스템 네트워크 설정 패널을 열어 프록시 주소가 127.0.0.1과 해당 포트(보통 7890 전후)로 되어 있는지 확인합니다. 비어 있거나 시스템 기본값으로 되어 있으면 안 됩니다.
• 해결 조치: 클라이언트 메인 화면에서 "시스템 프록시" 스위치를 수동으로 켜고, 네트워크 설정 패널을 다시 새로고침하여 정상적으로 적용되었는지 확인합니다.

2. 프록시 모드를 잘못 선택했는가

Clash는 일반적으로 세 가지 프록시 모드를 제공합니다: 규칙 모드(Rule), 글로벌 모드(Global), 직접 연결 모드(Direct). 모드가 잘못하여 직접 연결로 설정되어 있으면, 모든 트래픽이 프록시를 거치지 않고 바로 나가며, 노드 상태는 정상으로 표시되지만 실제로는 어떤 트래픽도 프록시 서버를 경유하지 않습니다.

• 확인 방법: 클라이언트 설정 영역의 모드 선택을 확인하여 현재 선택된 항목이 "직접 연결"이 아닌지 확인합니다. 평소 규칙 모드를 사용하는데 접속 불가한 사이트가 유독 많다면, 임시로 글로벌 모드로 전환해 비교 테스트를 해볼 수도 있습니다.
• 해결 조치: 규칙 모드나 글로벌 모드로 다시 전환하고, 문제가 바로 사라지는지 관찰합니다.

3. 로컬 네트워크 연결과 포트 충돌

라우터나 다른 기기를 통해 Clash가 실행 중인 호스트로 트래픽을 전달하는 경우, "로컬 네트워크 연결 허용" 옵션을 추가로 켜야 합니다. 또한 프록시 포트가 실행 중인 다른 프로그램에 의해 이미 사용되고 있지 않은지 확인해야 합니다——예를 들어 다른 프록시 도구를 동시에 켜놓으면 같은 포트를 두 프로그램이 경쟁하게 되어 프록시 요청이 조용히 무시될 수 있습니다.

• 확인 방법: 클라이언트 설정에서 "로컬 네트워크 연결 허용" 스위치 상태를 확인합니다. 명령줄 도구로 포트 점유 상황을 확인합니다.
• 해결 조치: 충돌하는 프로그램을 종료하거나 Clash의 수신 포트를 변경한 뒤, 클라이언트를 재시작하여 설정을 적용합니다.

체크포인트 4~6: 노드 자체의 사용 가능 여부 검증

4. 노드 지연 테스트 결과

클라이언트에 표시되는 지연 값(ms)은 대개 노드 서버에 대한 연결성 테스트 결과입니다. 값이 정상이면 서버가 온라인 상태이며 네트워크로 도달 가능함을 의미합니다. 타임아웃이나 매우 높은 지연이 표시되면 이는 노드 자체의 문제이며 로컬 설정과는 무관합니다.

• 확인 방법: 프록시 그룹 목록에서 수동으로 지연 테스트를 실행하고, 현재 선택된 노드가 타임아웃(보통 빨간색 또는 timeout으로 표시)으로 나타나는지 중점적으로 확인합니다.
• 해결 조치: 현재 노드가 타임아웃이라면 지연이 정상인 다른 노드로 전환합니다. 구독 내 모든 노드가 전부 타임아웃이라면 문제는 구독 자체나 로컬 네트워크 환경에 있을 수 있으므로 체크포인트 1~2로 돌아가 다시 확인해야 합니다.

5. 프록시 그룹의 자동 선택 로직

많은 구독 설정의 "자동 선택" 프록시 그룹은 지연이나 생존 상태를 기반으로 실제 사용 노드를 자동으로 전환합니다. 이 자동 선택 그룹이 현재 가리키고 있는 실제 노드가 마침 장애가 났다면, 그룹 내에 다른 정상 노드가 있더라도 전환 지연 때문에 현재 세션이 잠시 인터넷에 접속하지 못할 수 있습니다.

• 확인 방법: 자동 선택 그룹을 펼쳐서 현재 실제로 적용 중인 하위 노드의 지연이 비정상적인지 확인합니다.
• 해결 조치: 자동 선택 그룹에 의존하지 않고, 이미 확인된 사용 가능한 특정 노드로 수동으로 강제 전환하여 자동 전환 로직으로 인한 간섭을 배제합니다.

6. 노드 프로토콜과 서버 측 설정이 일치하는가

수동으로 추가하거나 수정한 노드(구독으로 생성된 설정을 그대로 사용하지 않은 경우), 프로토콜 유형, 암호화 방식, 전송 계층 설정 등의 파라미터가 서버 측과 일치하지 않으면 "연결은 되지만 유효한 세션을 맺지 못하는" 상황이 발생하며, 이 역시 지연은 정상이지만 페이지가 열리지 않는 형태로 나타납니다.

• 확인 방법: 노드 파라미터와 서버 제공자가 준 원본 설정이 완전히 일치하는지 대조합니다. 특히 전송 프로토콜과 암호화 방식 두 항목을 주의해서 확인합니다.
• 해결 조치: 구독 링크에서 설정을 다시 생성하여 수동 입력으로 인한 파라미터 오류를 피합니다.

체크포인트 7~9: DNS와 규칙 레벨의 점검

7. DNS 해석이 오염되었는가

일부 네트워크 환경은 DNS 쿼리를 가로채거나 조작합니다. 프록시 자체는 정상 작동하더라도, 도메인 해석 단계에서 이미 잘못된 IP 주소가 반환되었다면 이후 요청은 계속 실패하거나 잘못된 서버로 향하게 됩니다. 이 경우 프록시 지연 테스트는 완전히 정상일 수 있지만 웹페이지는 계속 열리지 않습니다.

• 확인 방법: 프록시를 켠 상태와 끈 상태에서 같은 도메인이 해석되는 IP 주소가 다른지 비교합니다. 클라이언트 로그의 DNS 쿼리 기록을 직접 확인해도 됩니다.
• 해결 조치: 설정 파일에서 Clash 자체의 DNS 모듈을 활성화하여 도메인 해석을 시스템 기본 DNS가 아닌 Clash가 처리하도록 하고, 필요하다면 fake-ip 모드를 켜서 해석 결과가 로컬 네트워크 환경에 의해 조작되는 것을 근본적으로 방지합니다.

8. 규칙이 트래픽을 잘못 DIRECT로 판정하는가

규칙 모드에서는 설정 파일의 규칙 세트가 요청된 도메인이나 IP를 한 줄씩 매칭합니다. 어떤 DIRECT 규칙에 매칭되는 순간 트래픽은 프록시를 거치지 않고 직접 연결됩니다. 규칙 세트 버전이 오래되었거나 규칙 순서가 잘못되어 있으면, 원래는 프록시를 거쳐야 할 도메인이 앞서 직접 연결 규칙에 먼저 매칭될 수 있습니다. 특히 사용자 정의 규칙이나 여러 규칙 세트를 겹쳐 사용하는 설정에서 이런 문제가 자주 발생합니다.

• 확인 방법: 클라이언트의 연결 로그나 규칙 매칭 기록을 확인하여 대상 도메인이 실제로 어떤 규칙에 매칭되었는지, 어떤 출구 정책 그룹을 거쳤는지 확인합니다.
• 해결 조치: 규칙 순서를 조정하여 더 정확한 프록시 규칙을 넓은 범위의 직접 연결 규칙보다 앞에 배치하거나, 규칙 세트를 최신 버전으로 업데이트합니다. 임시로 검증할 때는 글로벌 모드로 전환해 규칙 간섭을 배제할 수도 있습니다.

9. 아웃바운드 정책 그룹이 가리키는 노드 그룹이 비어 있거나 전부 장애 상태인가

일부 설정은 트래픽 유형별(예: 스트리밍, 소셜 앱, 국내 직접 연결)로 독립된 정책 그룹을 만들고, 정책 그룹 내부에서 다시 구체적인 노드를 참조합니다. 어떤 정책 그룹이 필터링 조건이 너무 엄격해 그룹 내에 사용 가능한 노드가 없다면, 이 정책 그룹에 매칭되는 트래픽은 기본 프록시 그룹이 정상 작동하더라도 바로 실패합니다.

• 확인 방법: 설정 파일에 정의된 정책 그룹을 하나씩 확인하여 각 그룹에 최소 하나 이상의 현재 사용 가능한 노드가 포함되어 있는지 확인합니다.
• 해결 조치: 정책 그룹의 노드 출처를 보충하거나, 비어 있는 정책 그룹을 임시로 기본 프록시 그룹으로 지정하여 특정 유형의 트래픽이 갈 곳을 잃지 않도록 합니다.

9가지 점검을 하나의 점검 경로로 연결하기

실제로는 번호 순서대로 하나씩 끝까지 마쳐야 결론을 낼 수 있는 것은 아닙니다. 더 효율적인 방법은 먼저 두 번의 빠른 판단으로 범위를 줄이는 것입니다: 첫 번째로 "로컬 설정 문제인가"를 판단——임시로 글로벌 모드로 전환합니다. 문제가 사라지면 규칙이나 DNS 레벨의 문제일 가능성이 높습니다(체크포인트 7~9). 전환 후에도 여전히 인터넷이 안 된다면 시스템 프록시 스위치, 포트 충돌, 노드 자체 상태를 중점적으로 점검합니다(체크포인트 1~6).

9가지 점검을 모두 마쳤는데도 문제가 여전하다면, 클라이언트 로그 스크린샷을 보관하고 구독을 새로 불러와 완전히 새로운 설정 파일을 생성해 비교 테스트를 해보는 것을 권장합니다——때로는 문제가 로컬에서 오랫동안 누적된 수정 사항이 담긴 설정 파일 자체에 있으며, 깨끗한 설정 하나가 기존 설정을 계속 파헤치는 것보다 시간을 훨씬 절약해 줍니다.

# 프록시가 적용되었는지 빠르게 확인하는 명령줄 방법 (Windows / macOS 모두 유사한 문법 사용 가능)
curl -x http://127.0.0.1:7890 https://www.google.com -I

# HTTP 상태 코드가 반환되고 타임아웃이나 연결 거부가 아니라면 프록시 경로 자체는 정상입니다
# 이 경우 문제는 대개 DNS 해석이나 규칙 매칭 단계에 있습니다