MIHOMO / DIAGNOSTICS

Clash 애플판 문제 해결 가이드

증상에 따라 로컬 네트워크, 프록시 진입점, 규칙, DNS 및 원격 연결을 점검하세요. 먼저 문제가 발생한 계층을 파악한 뒤 해당 설정을 변경하면 됩니다.

macOS · Apple Silicon iOS · iPadOS arm64 · mihomo

처음 설치하거나 구독을 가져오는 경우 먼저 빠른 시작을 확인하세요. 이 페이지는 연결 문제를 해결하기 위한 참고 자료이며, 최초 설정 과정을 대신하지 않습니다. 클라이언트 선택 시 Clash Plus를 우선 추천합니다. 설치 링크와 다른 옵션은 클라이언트 다운로드에서 확인하세요. 아래 mihomo 설정값은 해당 코어를 사용하는 클라이언트에 적용됩니다. 다른 앱은 지원하는 설정 형식에 맞춰야 합니다.

인터넷 연결 불가: 직접 연결과 프록시 경로 분리하기

바로 재설치하지 말고 프록시 경로를 끈 상태에서 기본 연결부터 테스트하세요. 클라이언트의 시스템 프록시와 TUN을 끈 뒤 앱을 종료합니다. iPhone에서는 해당 VPN 연결을 끊으세요. 평소 직접 접속할 수 있는 사이트를 브라우저에서 열고, 같은 네트워크에 연결된 다른 기기에서도 확인합니다. 두 기기 모두 연결되지 않으면 Wi-Fi, 라우터 또는 통신사 네트워크를 먼저 점검하세요. 현재 기기에서만 문제가 발생하면 남아 있는 프록시 설정, 다른 VPN 및 기기 자체 DNS를 확인합니다. 기본 연결이 복구되기 전에는 노드 테스트 결과를 신뢰할 만한 기준으로 비교할 수 없습니다.

재현 가능한 로컬 네트워크 기준 만들기

macOS에서 ‘시스템 설정 → 네트워크’를 열고 현재 Wi-Fi와 이더넷 중 어떤 연결을 사용 중인지 확인하세요. 호텔, 공항, 학교 네트워크는 웹 인증이 필요할 수 있습니다. Wi-Fi에 연결되었다고 인터넷 사용 권한까지 얻은 것은 아닙니다. VPN을 잠시 끊고 인증을 마친 뒤 프록시를 다시 연결하세요. 시스템 시간도 정확해야 합니다. 시간이 맞지 않으면 TLS 인증서 검증이 실패해 여러 HTTPS 사이트에서 동시에 오류가 발생할 수 있으며, 단순한 Wi-Fi 연결 끊김과는 다릅니다.

그다음 프록시 클라이언트 하나만 실행하고 TUN은 켜지 마세요. 설정이 선택되어 있고 코어가 실행 중인지 확인한 뒤 시스템 프록시를 활성화합니다. 여러 앱이 시스템 프록시를 동시에 변경하면 이미 종료된 다른 프로세스의 주소가 남을 수 있습니다. 터널을 여러 개 동시에 켜면 라우팅 경로를 파악하기도 어려워집니다. 업무용 VPN이 필요하다면 유지하되, 테스트할 때마다 VPN의 켜짐 여부를 기록해 동일한 조건을 유지하세요.

명시적 프록시로 진입점과 출구 구분하기

아래 명령은 각각 프록시를 우회하는 경우와 로컬 HTTP 프록시를 지정하는 경우를 테스트하며, 응답 헤더만 읽습니다. 포트 7890은 예시이므로 클라이언트에 표시된 실제 혼합 포트로 바꿔야 합니다. 테스트 대상은 접속이 확인된 사이트로 바꿔도 됩니다. 명령이 성공해도 해당 대상까지의 경로만 작동한다는 뜻이며, 모든 앱이나 UDP, 모든 규칙이 정상이라는 의미는 아닙니다.

# macOS: 프록시 환경 변수를 무시하고 직접 연결 테스트
curl -I --noproxy '*' --connect-timeout 10 --max-time 20 https://www.apple.com/

# 클라이언트에서 실제로 수신 중인 혼합 포트를 명시
curl -I --proxy http://127.0.0.1:7890 --noproxy '' \
  --connect-timeout 10 --max-time 20 https://www.apple.com/

명시적 프록시 테스트에서 즉시 연결 거부가 표시되면 보통 로컬 진입점에 문제가 있습니다. 코어가 실행되지 않았거나 포트가 잘못되었거나 수신에 실패했을 수 있습니다. 연결을 기다리다 시간 초과되면 클라이언트 연결 기록을 확인해 어떤 정책과 노드가 선택되었는지 살펴보세요. 명시적 프록시는 성공하지만 브라우저가 실패한다면 원격 노드를 반복해서 바꾸기보다 시스템 프록시 오류를 확인하세요. 직접 연결은 되고 프록시 연결만 실패하면 설정, 규칙 및 원격 경로로 문제 범위를 좁힐 수 있습니다.

규칙, DNS 및 터널 경로 확인

잠시 규칙 모드를 전역 모드로 바꾸고, 작동이 확인된 프록시 노드 하나를 직접 선택한 뒤 같은 사이트에 접속하세요. 전역 모드에서는 정상인데 규칙 모드에서만 실패하면 대상 도메인의 매칭 규칙, 정책 그룹 선택 및 직접 연결 경로를 확인합니다. 테스트가 끝나면 규칙 모드로 되돌리세요. 전역 모드는 트래픽 분기 정책만 바꿉니다. 시스템 프록시를 사용하지 않는 앱을 자동으로 클라이언트에 연결하지 않으며, TUN이 작동한다는 증거도 아닙니다.

브라우저에 서버를 찾을 수 없다는 메시지가 표시되면 먼저 DNS 섹션을 확인하세요. TUN을 켰을 때만 문제가 발생한다면 TUN을 끄고 다시 테스트한 뒤 보조 서비스, 기본 경로 및 DNS 가로채기 설정이 다른 터널과 충돌하는지 확인합니다. 이때 게이트웨이를 직접 수정하거나 모든 네트워크 서비스를 삭제하거나 시스템 파일을 지우지 마세요. 먼저 ‘시스템 프록시가 작동하는’ 최소 상태로 복구한 다음, 트래픽을 제어하는 범위를 하나씩 늘리세요.

노드 시간 초과: 탐지 실패와 실제 연결 실패 구분하기

노드 지연 시간이 시간 초과로 표시되어도 노드가 반드시 오프라인인 것은 아닙니다. 지연 시간 탐지는 보통 노드를 통해 특정 테스트 주소에 접속하므로 테스트 대상, DNS, 노드 출구 및 시간 초과 설정의 영향을 함께 받습니다. 해당 노드를 선택하고 브라우저와 명시적 프록시로 각각 다른 대상 두 곳에 접속한 뒤 연결 로그를 확인하세요. 탐지만 실패하고 실제 웹사이트 접속은 정상이라면 탐지 주소와 방식을 점검합니다. 실제 접속도 실패할 때 서버 연결과 프로토콜 설정을 확인하세요.

실패가 발생한 단계 확인

로그의 연결 거부, 연결 시간 초과, 인증서 오류 및 인증 실패는 각각 의미가 다릅니다. 연결 거부는 보통 대상 주소에 도달했지만 해당 포트에서 연결을 받지 않는다는 뜻입니다. 연결 시간 초과는 패킷 손실, 방화벽 또는 주소에 도달할 수 없는 상황에서 발생할 수 있습니다. 인증 실패는 비밀번호, 사용자 식별 정보 또는 서버 설정을 가리킵니다. 인증서 오류가 발생하면 시간, 서버 이름 및 인증서 신뢰 체인을 확인하세요. 화면의 ‘실패’라는 문구만 캡처하지 말고 오류 하나와 앞뒤 관련 로그를 함께 보관하세요.

현재 선택한 항목이 개별 노드인지, 자동 선택·장애 조치·부하 분산 정책 그룹인지 먼저 확인하세요. 정책 그룹에 표시된 이름이 이번 연결에서 실제로 사용된 출구와 다를 수 있습니다. 연결 상세 정보를 열어 대상, 적용 규칙, 정책 경로 및 실제 노드를 살펴보세요. 규칙에 따라 직접 연결된 요청이라면 노드 탐지 결과와 같은 경로가 아니므로 함께 비교하면 안 됩니다.

서버 도메인 및 프로토콜 설정 확인

구독은 정상적으로 다운로드되지만 모든 노드가 시간 초과된다면 비밀번호를 전부 바꾸기 전에 노드 서버 도메인이 해석되는지 확인하세요. 서버 도메인은 일반 웹사이트 DNS와 다른 경로를 사용하는 proxy-server-nameserver로 해석될 수 있습니다. 해석 결과에 IPv6 주소가 포함되어 있고 현재 네트워크의 IPv6 경로에 문제가 있으면 네트워크에 따라 접속이 되거나 오래 기다리는 현상이 나타날 수 있습니다. 주소 유형과 오류를 함께 기록한 뒤 설정을 조정하세요.

노드 하나만 실패한다면 구독의 원본 설정을 기준으로 주소, 포트, 전송 방식, TLS, SNI 및 클라이언트 코어의 지원 여부를 확인하세요. 노드 IP를 SNI에 넣거나 인증서 오류를 없애려고 인증서 검증 건너뛰기를 켜지 마세요. 도메인 검증을 사용하는 프로토콜에서는 연결 주소와 인증서 이름이 서로 다른 역할을 할 수 있습니다. 둘 중 하나를 임의로 바꾸면 기존 라우팅 문제가 핸드셰이크 오류로 바뀔 수 있습니다.

# 서버 도메인의 해석 결과 확인
# example.com은 예시 도메인입니다. 문제를 확인할 때 실제 노드 서버 도메인으로 바꾸세요
dscacheutil -q host -a name example.com

# TCP 포트 연결만 테스트하며 프록시 인증이나 UDP는 확인하지 않습니다
nc -vz -G 5 example.com 443

위 TCP 테스트가 성공해도 TCP 연결이 성립했다는 의미일 뿐, 프록시 프로토콜 인증, UDP 전달 또는 대상 웹사이트 접속까지 확인한 것은 아닙니다. UDP 기반 프로토콜이라면 이 테스트는 해당 전송 경로를 검증하지도 않습니다. 따라서 서버가 완전히 정상이라고 판단해서는 안 됩니다. 명령이 실패했다면 실제 포트를 사용했는지 확인하고, 현재 네트워크에서 해당 전송 유형을 허용하는지도 고려하세요.

네트워크를 바꿔 비교해 외부 제한 파악하기

노드와 설정을 그대로 둔 채 집 Wi-Fi와 휴대폰 핫스팟에서 각각 테스트하세요. 핫스팟에서는 정상이고 기존 네트워크에서만 실패한다면 네트워크 접근 정책, UDP 제한 또는 라우팅 품질을 점검해야 합니다. 두 네트워크 모두에서 실패하지만 다른 노드는 정상이라면 해당 노드나 서버 설정에 문제가 있을 가능성이 큽니다. 많은 노드를 짧은 간격으로 연속 탐지하지 마세요. 서버 제한을 유발하거나 연결 부하를 늘려 진단을 방해할 수 있습니다.

현재 코어가 프로토콜을 지원하지 않는다면 다운로드 페이지에서 필요한 프로토콜을 지원하고 유지 관리 중인 클라이언트를 선택하세요. Apple 기기에서는 Clash Plus를 먼저 고려한 뒤 사용 환경에 맞춰 다른 옵션과 비교할 수 있습니다. 코어 이름과 클라이언트 화면의 이름은 같은 개념이 아닙니다. 자세한 내용은 Clash·Meta·mihomo 코어 차이를 확인하세요. 클라이언트를 바꾸기 전에 기존 설정을 보관하고, 변경 후에는 같은 노드만 테스트해야 합니다. 그래야 클라이언트 변경을 네트워크 복구의 근거로 오해하지 않습니다.

구독 오류: 다운로드·파싱·적용 단계별 확인

구독 문제는 크게 세 단계로 나뉩니다. 원격 콘텐츠 다운로드 실패, 다운로드한 콘텐츠가 유효한 설정이 아닌 경우, 유효한 설정이 활성화되지 않은 경우입니다. 먼저 오류가 어느 단계에서 발생했는지 확인하세요. 비정상 HTTP 상태 코드, 연결 시간 초과 및 인증서 오류는 보통 다운로드 단계 문제입니다. YAML 행 번호, 필드 유형 및 미지원 프로토콜 오류는 파싱 단계 문제입니다. 업데이트가 성공했는데 노드가 바뀌지 않았다면 현재 설정 선택, 재정의 규칙 및 프록시 제공자 캐시를 확인하세요. 진단 정보를 잃을 수 있으므로 구독을 반복해서 삭제하지 마세요.

다운로드 단계: 주소·권한·업데이트 경로

서비스 제공업체에서 전체 구독 주소를 다시 복사하고 앞뒤 공백, 줄바꿈 및 채팅 앱이 바꾼 문자가 없는지 확인하세요. 쿼리 매개변수가 포함된 주소에는 인증 정보가 들어 있을 수 있으므로 공개 게시판에 올리거나 출처가 불분명한 온라인 변환 사이트에 입력하지 마세요. 브라우저에서 서비스 업체 홈페이지가 열린다고 해서 구독 API 권한까지 유효한 것은 아닙니다. 홈페이지, 로그인 상태 및 구독 다운로드 API는 서로 다른 인증 경로를 사용하는 경우가 많습니다.

401 또는 403 상태 코드는 보통 인증 권한, 유효 기간 또는 접근 정책을 확인해야 한다는 뜻입니다. 404는 경로가 바뀌었거나 주소가 만료되었을 수 있습니다. 429는 요청이 너무 많다는 의미이므로 계속 업데이트를 누르지 말고 기다리세요. 성공 상태 코드가 반환되어도 본문이 로그인 화면, 인증 페이지 또는 오류 안내라면 YAML 설정으로 가져올 수 없습니다. 클라이언트가 제공하는 응답 요약만 확인하고 로그에 전체 인증 정보를 남기지 마세요.

일부 클라이언트에서는 구독 업데이트를 직접 연결과 프록시 중 어느 쪽으로 보낼지 지정할 수 있습니다. 첫 구독을 가져올 때는 현재 프록시가 아직 작동하지 않아 ‘연결하려면 구독이 필요한데 구독을 업데이트하려면 연결이 필요한’ 상황이 생길 수 있습니다. 허용된 네트워크에서는 직접 연결로 업데이트하거나 이미 작동하는 별도 연결을 통해 설정을 가져오세요. 문제가 발생 중인 노드를 거쳐 업데이트 요청을 보내도록 무조건 설정하지 마세요. 경로를 바꾼 뒤 한 번만 업데이트하고 오류가 달라졌는지 기록하세요.

파싱 단계: 노드 문자열과 전체 YAML 구분

일반 Base64 노드 문자열, 단일 프로토콜 링크 및 Clash YAML은 서로 다른 형식입니다. 전체 설정에는 proxies, proxy-groups, rules 같은 필드가 포함될 수 있습니다. 노드 목록은 프록시 제공자로 추가해야 할 수도 있습니다. 먼저 가져오기 메뉴에서 어떤 형식을 지원하는지 확인한 뒤 변환 여부를 결정하세요. 관련 구조는 구독 형식 및 변환 방법에서 확인할 수 있습니다. 파일 확장자만 보고 콘텐츠 형식을 판단하지 마세요.

파싱 오류에 행 번호가 표시되면 해당 행뿐 아니라 바로 앞 행도 살펴보세요. 콜론 누락, 탭 들여쓰기, 닫히지 않은 따옴표, 같은 수준의 목록에서 들여쓰기가 서로 다른 경우 다음 행에서 오류가 발생할 수 있습니다. 아래는 구조를 이해하기 위한 로컬 예시이며 실제로 연결할 수 있는 프록시 노드는 포함하지 않습니다. 원격 전체 설정을 덮어쓴다고 노드가 자동으로 생기지는 않습니다.

mixed-port: 7890
allow-lan: false
mode: rule
proxies: []
proxy-groups:
  - name: 수동 선택
    type: select
    proxies:
      - DIRECT
rules:
  - MATCH,수동 선택

적용 단계: 설정 및 재정의 출처 확인

업데이트가 끝나면 화면에서 현재 선택된 설정이 방금 업데이트한 항목인지 확인하세요. 일부 클라이언트에서는 다운로드, 저장, 활성화가 각각 별도 작업입니다. 프록시 제공자는 별도의 새로고침 주기를 사용할 수도 있습니다. 구독 카드의 업데이트 시간만 보지 말고 현재 정책 그룹의 구성원과 로드 로그를 확인하세요. 노드 수는 바뀌었지만 규칙이 그대로라면 원격 업데이트 실패가 아니라 템플릿이나 재정의 설정이 로컬 규칙을 유지했을 수 있습니다.

원격 설정은 다음 업데이트 때 덮어써지는 경우가 많으므로, 계속 유지할 변경 사항은 클라이언트에서 지원하는 재정의·병합·확장 설정에 두세요. 문제를 찾을 때는 불필요한 재정의를 먼저 끄고 원본 파일을 복사해 보관한 뒤 원래 구독을 불러와 비교합니다. 원본 설정은 작동하지만 병합 후 오류가 발생한다면 재정의를 하나씩 적용해 충돌 지점을 찾으세요. 원격 파일과 로컬 템플릿을 동시에 수정하면 최종 적용된 내용을 확인하기 어렵습니다.

속도 저하: 지연 시간·전송 속도·앱 동작을 나눠 측정

지연 시간이 짧아도 대용량 파일 다운로드가 빠르다는 보장은 없으며, 지연 시간이 길다고 전송 속도가 반드시 느린 것도 아닙니다. 웹페이지 체감 속도는 DNS, 핸드셰이크 횟수, 리소스 수 및 대상 서비스의 제한에도 영향을 받습니다. 먼저 증상을 구체적으로 정리하세요. 처음 열 때만 느린지, 다운로드 내내 느린지, 동영상이 버퍼링되는지, 특정 앱만 느린지 구분해야 합니다. 같은 기기, 네트워크, 대상 및 비슷한 시간대를 유지해 비교하세요. 서로 다른 속도 측정 사이트나 콘텐츠 전송 경로의 결과를 그대로 순위화하지 마세요.

최소 테스트 조합 만들기

먼저 프록시를 끈 상태에서 직접 접속 가능한 사이트를 열어 로컬 Wi-Fi와 인터넷 회선에 뚜렷한 병목이 없는지 확인하세요. 다음으로 노드 하나를 고정하고 같은 대상에 명시적 프록시와 일반 브라우저로 접속해 비교합니다. 그다음 노드만 바꾸고 동일한 테스트를 반복하세요. 모든 노드에서 느리지만 직접 연결은 정상이라면 클라이언트의 트래픽 처리 방식과 로컬 시스템 부하를 점검합니다. 노드 하나에서만 느리다면 전체 시스템 네트워크를 바꾸기보다 해당 노드의 출구와 대상 사이 경로를 확인하세요.

관찰 결과우선 의심할 항목다음 단계
처음 열 때 느리고 이후 정상DNS, 핸드셰이크 또는 캐시 초기화DNS 해석 및 연결 단계의 소요 시간 비교
작은 웹페이지는 정상, 대용량 전송은 멈춤패킷 손실, 경로 MTU, 출구 제한네트워크를 바꾸고 같은 전송 테스트
특정 앱만 느림트래픽 분기, UDP 또는 앱 자체 프록시해당 앱의 실제 연결 기록 확인
모든 접속이 느림로컬 네트워크, 시스템 부하 또는 터널 충돌다른 터널을 종료한 뒤 기본 상태 다시 확인

‘활성 상태 보기’에서 CPU, 메모리 및 네트워크 사용량도 확인하세요. 백그라운드 동기화, 시스템 업데이트 및 클라우드 드라이브 업로드가 업로드 대역폭을 모두 사용하면 웹페이지의 응답 확인 패킷도 지연될 수 있습니다. 다운로드 대역폭이 꽉 차지 않아도 발생할 수 있는 현상입니다. 대용량 작업이 원인으로 확인되면 잠시 멈추고 다시 테스트하세요. 정체를 알 수 없는 시스템 프로세스는 종료하지 마세요. 진단 로그를 가장 상세한 수준으로 장시간 유지하면 디스크 쓰기 부하가 커지고 민감한 연결 정보도 쌓일 수 있습니다.

DNS·핸드셰이크·다운로드 단계 구분

아래 명령으로 DNS, TCP, TLS 및 전체 소요 시간을 확인해 단서를 얻을 수 있습니다. HTTP 프록시를 사용하면 일부 값은 로컬 프록시까지의 과정을 나타낼 수 있으며, 대상 도메인의 DNS 해석은 프록시에서 처리될 수 있습니다. 따라서 time_namelookup을 원격 DNS 전체 소요 시간으로 간주하면 안 됩니다. 클라이언트 로그와 함께 확인해 어느 단계에서 지연되는지 판단하고, 한 가지 수치만으로 결론 내리지 마세요.

curl --proxy http://127.0.0.1:7890 --noproxy '' \
  --connect-timeout 10 --max-time 30 \
  -o /dev/null -sS \
  -w 'dns=%{time_namelookup}\ntcp=%{time_connect}\ntls=%{time_appconnect}\nfirst=%{time_starttransfer}\ntotal=%{time_total}\n' \
  https://www.apple.com/

TLS가 빠른데 첫 바이트를 기다리는 시간이 길다면 대상 서버의 응답과 출구 경로를 추가로 확인하세요. 연결 단계에서 재시도가 반복되면 패킷 손실, 주소 유형 및 노드 연결 상태를 살펴보세요. 작은 요청 하나로 지속적인 전송 속도를 판단할 수는 없으며, 속도 측정 파일이 서버에서 제한될 수도 있습니다. 더 높은 수치를 얻으려고 대용량 파일을 여러 개 동시에 다운로드하지 마세요. 구독 데이터를 소모하고 대상 서비스의 제한을 유발할 수 있습니다.

UDP·MTU 및 아키텍처 차이 확인

동영상, 화상 회의 및 게임은 UDP나 QUIC을 사용할 수 있으므로 일반 브라우저 HTTPS 테스트만으로 해당 경로를 확인할 수 없습니다. 앱 트래픽이 TUN에 들어가는지, 노드가 필요한 전달 방식을 지원하는지, 현재 네트워크에서 UDP를 제한하는지 확인하세요. 앱이 지원하는 전송 방식 전환 기능이 있다면 임시로 비교해 볼 수 있습니다. 모든 UDP를 끄는 것은 범용적인 최적화가 아닙니다. 앱 동작이 바뀌거나 통화가 연결되지 않을 수 있습니다.

MTU 불일치는 작은 요청은 성공하지만 대용량 전송이 멈추는 원인이 될 수 있으나, 모든 속도 저하의 해결책은 아닙니다. 네트워크 변경, 로그 및 전송 증상이 이 가능성을 뒷받침할 때만 해당 설정을 지원하는 TUN 구성에서 조금씩 조정하세요. 기존 값을 기록하고 변경할 때마다 테스트합니다. Apple Silicon Mac에서는 변수를 줄이기 위해 arm64 빌드를 우선 사용하세요. 다만 아키텍처를 바꿔도 원격 회선의 용량이 늘어나지는 않습니다. 클라이언트별 차이는 클라이언트 비교를 참고하세요.

“같은 대상이 핫스팟에서는 정상인데 집 네트워크에서는 계속 멈춘다”처럼 재현할 수 있는 결론을 남기세요. “모든 노드가 느리다”는 설명에는 노드, 대상 및 시간 등 여러 변수가 섞여 있습니다. 앞의 결과는 라우터, 네트워크 정책 또는 경로 문제를 점검하는 데 활용할 수 있습니다. 조정이 끝나면 평소 로그 수준으로 되돌리고 실제 업무 앱으로 확인하세요. 속도 측정 한 번으로 문제 해결을 끝내지 마세요.

DNS 문제: 해석 경로·fake-ip·유출 범위 점검

DNS 문제를 확인할 때는 세 가지를 파악해야 합니다. 누가 조회를 시작하는지, 어떤 DNS 서버에 조회를 보내는지, 조회 결과를 누가 연결에 사용하는지입니다. 시스템 DNS, 브라우저 보안 DNS, 클라이언트 내장 DNS 및 노드 서버 도메인 해석이 동시에 사용될 수 있습니다. 웹페이지가 열리지 않는다고 반드시 DNS 오류인 것은 아니며, DNS 테스트 페이지에 특정 지역이 표시된다고 예상한 경로를 우회했다는 뜻도 아닙니다. 먼저 도메인이 해석되는지 확인한 뒤 클라이언트 연결 기록 및 실제 출구와 대조하세요.

시스템 DNS와 클라이언트 DNS 구분

macOS에서 scutil --dns를 사용하면 리졸버와 적용 범위를 확인할 수 있습니다. 출력에는 기본 리졸버, 인터페이스별 리졸버 및 VPN에서 제공하는 리졸버가 포함될 수 있습니다. 첫 번째 항목만 보고 모든 도메인의 경로를 판단하지 마세요. 회사 내부 도메인은 분할 DNS가 필요할 수 있습니다. 모든 DNS를 공용 DNS로 바꾸면 내부 리소스에 접속하지 못할 수 있습니다. 브라우저에서 별도의 보안 DNS를 사용하면 시스템 DNS와 다른 경로로 조회될 수도 있습니다.

# macOS의 현재 리졸버 및 적용 범위 확인
scutil --dns

# 시스템 인터페이스를 통해 예시 도메인 조회
dscacheutil -q host -a name www.apple.com

# 설정 변경 후 기존 캐시를 지워야 할 때만 실행
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

캐시를 지워도 오래된 결과만 제거될 뿐, 상위 DNS 서버나 라우팅 문제는 해결되지 않습니다. dig 같은 도구로 특정 DNS 서버에 조회를 보낼 수 있지만, 기본 동작이 macOS 앱의 전체 시스템 DNS 경로와 같다고 볼 수는 없습니다. 명령줄과 브라우저 결과가 다르면 먼저 조회 경로와 캐시를 확인하세요. 한쪽 도구가 작동하지 않는다고 바로 판단하지 마세요. 암호화 DNS를 사용할 때는 DNS 서버 도메인 자체를 조회할 수 있는 초기 연결 경로도 확인해야 합니다.

fake-ip가 트래픽을 제어하는 조건 이해

mihomo의 fake-ip 모드는 앱에 매핑된 주소를 반환한 뒤 코어가 연결을 원래 도메인과 연결하도록 합니다. 이 주소는 실제 대상 서버 주소가 아니므로, fake-ip가 보인다는 사실만으로 DNS가 오염되었다고 볼 수 없습니다. 중요한 것은 이후 연결도 같은 코어가 처리하는지입니다. 앱이 매핑 주소를 캐시한 상태에서 클라이언트가 종료되었거나, 시스템 DNS가 클라이언트를 가리키는데 DNS 수신 서비스가 중지되었다면 프록시를 끊은 뒤에도 접속할 수 없는 문제가 생길 수 있습니다.

# mihomo DNS 설정 예시이며 전체 구독 설정이 아닙니다
dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - https://1.1.1.1/dns-query

이 예시는 로컬 루프백 주소에서만 요청을 받으며, 선택한 상위 DNS 서버는 현재 네트워크에서 접속 가능해야 합니다. 일반적인 시스템 DNS 설정에는 1053 같은 사용자 지정 포트를 바로 입력할 수 없습니다. 이 포트에서 수신을 켜는 것만으로 모든 시스템 조회가 자동으로 전달되지는 않습니다. 클라이언트에서 제공하는 DNS 제어, TUN 가로채기 또는 명시적인 설정으로 연결해야 합니다. GUI 클라이언트가 관련 필드를 덮어쓸 수도 있으므로 실제로 불러온 설정과 시작 로그를 확인하세요.

증상에 따라 해결 방법 선택

로컬 네트워크 기기 이름, 프린터 또는 회사 도메인만 실패한다면 전체 도메인을 직접 연결로 보내지 말고 로컬 기기 검색, 분할 DNS 및 fake-ip 필터 규칙을 확인하세요. 호환되지 않는 것으로 확인된 도메인만 클라이언트에서 지원하는 필터 목록에 추가하고 내부 DNS 경로는 유지합니다. 노드 도메인도 해석되지 않으면 먼저 노드의 초기 DNS 경로를 복구하세요. 아직 연결되지 않은 노드를 통해 해당 노드 자신의 서버 주소를 해석할 수는 없습니다.

프록시 연결은 정상인데 외부 검사에서 예상치 못한 DNS 서버가 표시된다면 브라우저의 별도 DNS를 끄고 비교한 뒤 TUN의 DNS 제어 범위, IPv6 및 우회 규칙을 확인하세요. DNS 조회가 직접 연결을 사용하고 서비스 트래픽은 프록시를 사용하는 것은 서로 별개의 설정입니다. 원하는 개인정보 보호 범위에 맞는지 판단해야 합니다. 특정 검사 사이트는 설계된 조회 방식만 확인하므로 모든 앱의 DNS가 제어된다는 보장은 아닙니다.

수정한 뒤 일반 도메인, 이전에 실패한 도메인 및 필요한 내부 도메인이 모두 해석되는지 확인하세요. 클라이언트를 한 번 끊었다가 다시 연결해 시스템 리졸버가 정상적으로 복구되는지도 살펴봅니다. 장기적으로는 설명하기 쉬운 DNS 구성을 하나 선택하고 시스템, 브라우저, 라우터 및 클라이언트의 전달 설정이 서로 의존하지 않도록 하세요. TUN 제어 방식을 변경해야 한다면 macOS TUN 권한 안내에서 구현 방식을 확인하세요.

시스템 프록시가 작동하지 않음: 설정·수신 상태·앱 연결 경로 확인

macOS 시스템 프록시는 앱이 참조하는 네트워크 설정이지, 모든 기기 트래픽을 강제로 전달하는 기능이 아닙니다. 브라우저는 시스템 프록시를 따를 수 있지만 명령줄, 게임 및 자체 네트워크 스택을 사용하는 앱은 따르지 않을 수 있습니다. 먼저 명시적 프록시로 클라이언트 진입점이 작동하는지 확인한 뒤 현재 네트워크 서비스에 시스템 설정이 적용되었는지 살펴보세요. 진입점은 정상인데 특정 앱이 직접 연결된다면 해당 앱의 프록시 지원 여부를 확인하세요. 시스템 프록시 스위치를 반복해서 켜고 끄기보다 필요한 경우 TUN을 고려합니다.

현재 네트워크 서비스에 설정이 적용됐는지 확인

‘시스템 설정 → 네트워크 → 현재 네트워크 서비스 → 세부사항 → 프록시’를 열고 웹 프록시와 보안 웹 프록시의 호스트 및 포트를 확인하세요. macOS 버전에 따라 메뉴 이름은 조금 다를 수 있지만, 실제 인터넷 연결에 사용 중인 서비스를 확인해야 합니다. Wi-Fi의 프록시 설정이 이더넷에도 자동으로 적용되는 것은 아닙니다. 도킹 스테이션, 핫스팟 또는 네트워크 위치를 바꾼 뒤에는 이전 서비스에 설정이 남아 있어도 현재 트래픽은 다른 서비스를 사용할 수 있습니다.

# 현재 프록시 설정 요약 확인
scutil --proxy

# 네트워크 서비스를 나열해 시스템 설정의 이름과 비교
networksetup -listallnetworkservices

# 이 Mac의 예시 포트에서 TCP 연결을 수신하는지 확인
lsof -nP -iTCP:7890 -sTCP:LISTEN

출력에서 HTTP, HTTPS, SOCKS 및 자동 프록시 설정은 각각 별도로 활성화될 수 있습니다. 수동 프록시와 PAC가 함께 설정되어 있다면 수동 설정이 항상 자동 설정을 덮어쓴다고 가정하지 말고, 앱에서 실제로 어느 설정을 사용하는지 확인하세요. 조직에서 관리하는 기기는 구성 프로파일의 제약을 받을 수 있습니다. 이런 경우 관리 설정을 임의로 삭제하지 말고 조직의 네트워크 지침을 따르세요. 클라이언트가 프록시 설정을 적용하지 못한다면 스위치 모양보다 로그에서 권한 문제를 확인하는 편이 정확합니다.

수신 주소와 혼합 포트 확인

수신 호스트는 보통 127.0.0.1이며 포트는 클라이언트의 실제 설정값을 사용합니다. 원격 노드 서버의 포트를 시스템 프록시 포트로 입력하거나 제어 인터페이스 포트와 혼동하지 마세요. 포트를 다른 프로세스가 사용 중이면 코어가 시작되지 않거나 시스템 프록시가 엉뚱한 앱을 가리킬 수 있습니다. 수신 확인 명령에 표시된 프로세스 이름으로 소유자를 확인한 뒤 해당 앱을 정상적으로 종료하세요. 알 수 없는 프로세스를 강제로 종료하지 마세요.

아래 최소 설정은 로컬 프록시 진입점만 보여 주며 원격 노드는 포함하지 않습니다. mixed-port는 HTTP와 SOCKS 프록시 프로토콜을 모두 수신합니다. DNS 포트와는 다르며 외부 웹사이트가 이 포트로 직접 접속해야 한다는 뜻도 아닙니다. GUI 클라이언트에 별도 포트 설정이 있다면 먼저 앱에서 변경하세요. 그래야 생성된 설정과 수동 편집이 서로 덮어쓰지 않습니다.

mixed-port: 7890
allow-lan: false
mode: rule

앱 자체 프록시와 터미널 환경 처리

터미널 프로그램은 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, NO_PROXY 같은 환경 변수를 읽을 수도 있고 자체 매개변수만 지원할 수도 있습니다. 비밀번호가 포함된 변수 값을 공개 로그에 붙여 넣지 마세요. 임시 명령 인수는 적용 범위가 분명해 진단에 적합합니다. 효과를 확인한 뒤 도구 설명에 따라 지속적으로 사용할 프록시를 설정하세요. HTTPS_PROXY가 가리키는 프록시 주소도 http://127.0.0.1:7890일 수 있습니다.

브라우저 확장 프로그램, 앱 내부 프록시 및 시스템 프록시 설정은 서로 덮어쓸 수 있습니다. 먼저 프록시 확장 프로그램을 끄고 새 창에서 다시 테스트하세요. 필요하면 앱을 완전히 종료한 뒤 다시 열어 기존 연결이 재사용되지 않도록 합니다. 연결이 이미 성립한 뒤 규칙이나 노드를 바꿔도 기존 연결의 출구가 바로 바뀌지는 않을 수 있습니다. 새 요청을 만들어 연결 기록에서 확인하세요. 오래 연결된 페이지를 새로고침하는 것만으로 판단하지 마세요.

앱이 시스템 프록시를 지원하지 않는 것이 확인되면 클라이언트의 TUN을 사용해 트래픽을 제어할 수 있습니다. 먼저 보조 서비스가 설치되어 있고 권한이 정상이며 다른 터널과 충돌하지 않는지 확인하세요. 클라이언트에 따라 보조 서비스나 시스템 네트워크 기능을 사용하므로 모두 같은 확장 프로그램을 설치해야 하는 것은 아닙니다. 클라이언트를 종료한 뒤 프록시 설정이 복구되었는지도 확인하세요. 네트워크가 끊기면 남아 있는 프록시를 먼저 끄고 이 섹션의 진입점 확인 절차를 따르세요. 보안 기능을 계속 꺼 둔 채로 두지 마세요.

앱 충돌: UI 종료·코어 중단·시스템 차단 구분

창이 사라지는 문제, 코어가 멈추는 문제, 시스템이 실행을 거부하는 문제는 각각 다릅니다. UI를 닫아도 코어가 계속 실행 중일 수 있고, 코어가 충돌해도 UI에 이전 상태가 표시될 수 있습니다. 실행 직후, 설정을 가져온 뒤, TUN을 켠 뒤 또는 절전 모드에서 깨어난 뒤 중 언제 발생하는지 기록하세요. 데이터 폴더 전체를 바로 삭제하지 마세요. 설정, 로그 및 충돌 보고서는 발생 조건을 파악하는 데 중요하며, 앱을 다시 설치해도 문제가 되는 상태가 남아 있을 수 있습니다.

아키텍처·배포 출처·시스템 알림 확인

Apple Silicon Mac에서는 arm64 또는 Apple Silicon 빌드를, Intel Mac에서는 x86_64 빌드를 우선 선택하세요. ‘이 Mac에 관하여’에서 칩 종류를 확인할 수 있습니다. Universal 빌드에는 두 아키텍처가 모두 포함될 수 있으므로 앱 안내를 따르세요. macOS 다운로드에서 설치 파일을 다시 선택해 오래된 복사본을 번갈아 실행하지 않도록 하세요. 클라이언트 선택 시 Clash Plus를 먼저 고려하고, 다른 앱은 시스템 요구 사항과 유지 관리 상태를 비교하세요.

앱이 손상되었다는 알림, 개발자 확인 또는 권한 제한이 표시되면 다운로드 출처와 클라이언트 배포 안내부터 확인하세요. 시스템 보안 기능을 끄는 명령을 바로 실행하지 마세요. 기업 기기는 앱 실행 정책의 영향을 받을 수도 있습니다. 설치 파일의 아키텍처 불일치, 지원되지 않는 시스템 버전 및 보안 차단은 모두 앱을 시작할 수 없는 것처럼 보이지만 해결 방법은 서로 다릅니다. 문제를 뭉뚱그려 ‘앱이 갑자기 종료됨’이라고 하지 말고 원래 표시된 알림 문구를 보관하세요.

증거를 먼저 수집한 뒤 최소 설정으로 실행

macOS ‘콘솔’에서 충돌 보고서를 확인하거나 클라이언트의 로그 메뉴를 통해 문제가 발생한 시간대의 기록을 내보내세요. 보고서가 GUI, mihomo 프로세스 또는 보조 서비스 중 무엇에 해당하는지 확인합니다. 최근에 재정의 설정을 추가했는지, 코어를 전환했는지, DNS를 변경했는지 또는 TUN을 켰는지 등 발생 절차와 마지막 변경 사항도 기록하세요. 로그에는 도메인, 서버 및 구독 정보가 포함될 수 있으므로 공유 전에 항목별로 가리고 사용자 디렉터리 전체를 묶어 보내지 마세요.

설정 사본을 보관한 뒤 자동 시작, 자동 연결 및 TUN을 끄고 최소 설정으로 실행한 다음 구독과 재정의를 단계적으로 복원하세요. 최소 설정에서는 정상이고 기존 설정에서 종료된다면 문제가 되는 필드나 규칙을 찾아 범위를 좁힙니다. 설정을 불러오기 전에도 종료된다면 앱 자체, 실행 환경 및 시스템 보고서를 먼저 확인하세요. 클라이언트가 안전 모드나 설정 복구 기능을 제공하면 공식 지원 방식부터 사용하고, 데이터 폴더 이름을 임의로 추측하지 마세요.

보조 서비스 및 리소스 이상 확인

TUN을 켰을 때만 실패한다면 보조 서비스가 현재 설치된 클라이언트에 속하는지, 업그레이드 후 복구가 필요한지, 다른 VPN이 경로를 선점하는지 확인하세요. 일반 사용자가 시스템 확장 파일을 직접 바꾸거나 시스템 시작 보안 수준을 낮춰서는 안 됩니다. 클라이언트에서 제공하는 서비스 설치·복구·제거 기능을 사용하세요. 화면에서 요구하는 권한이 배포 안내와 다르면 계속 권한을 부여하며 재시도하지 말고 설치 출처부터 확인하세요.

오래 실행한 뒤 종료된다면 메모리 압력, 로그 용량 및 연결 수의 변화도 확인하세요. 규칙 제공자가 자주 새로고침되거나 연결이 반복해서 재시도되거나 상세 로그가 계속 기록되면 시스템 부하가 커질 수 있습니다. 먼저 진단에 필요하지 않은 변수를 줄이세요. 일반 로그 수준으로 되돌리고 불필요한 새로고침을 일시 중지한 뒤 같은 작업을 재현합니다. 규칙을 전부 지우거나 인증서 검증을 꺼서 문제를 숨기지 마세요. 앱이 더 이상 종료되지 않더라도 기존 보안 및 트래픽 분기 기준을 잃게 됩니다.

Clash for Windows와 ClashX Meta는 보관된 구형 옵션입니다. 최신 시스템과 호환되지 않는 문제가 있다면 아직 유지 관리되는 대체 클라이언트를 우선 검토하고, 기존 설정을 새 앱에 그대로 덮어쓰지 마세요. 클라이언트마다 설정 병합, 보조 서비스 및 저장 방식이 다를 수 있습니다. 먼저 최소한의 구독 설정을 가져와 작동을 확인한 뒤 규칙과 기본 설정을 옮기세요. 그러면 기존 설정 문제와 새 클라이언트의 호환성 문제를 구분할 수 있습니다.

문제가 계속 재현된다면 시스템 및 아키텍처, 클라이언트 이름, 재현 절차, 최소 설정과 민감 정보를 가린 로그를 정리해 프로젝트나 앱의 공식 지원 창구에 전달하세요. 버전 정보를 지어내거나 화면에 표시된 실제 식별 정보 대신 ‘최신 버전’이라고만 쓰지 마세요. 복구한 뒤 자동 연결을 다시 켜고 정상 종료와 재시작을 테스트해 시스템 프록시가 남거나 백그라운드 서비스가 작동하지 않는 문제가 없는지 확인하세요.

모바일 문제: iPhone·iPad·Android 네트워크 전환

모바일에서는 먼저 시스템 VPN 상태와 앱 내부 연결 상태가 일치하는지 확인한 뒤 Wi-Fi와 셀룰러 중 현재 네트워크를 확인하세요. iOS 프록시 앱은 시스템에서 허용하는 네트워크 확장 기능으로 작동하므로 macOS의 보조 서비스나 터미널 명령을 그대로 적용할 수 없습니다. iPhone과 iPad에서는 Clash Plus를 먼저 고려하세요. 앱 스토어와 공식 웹사이트 링크는 iOS 클라이언트에서 확인할 수 있습니다. 설정 형식, 사용 가능한 규칙 및 기능 스위치는 앱 자체의 지원 여부에 따라 달라집니다.

iOS 연결은 됐지만 인터넷에 접속할 수 없음

먼저 앱에서 연결을 끊은 다음 ‘설정 → 일반 → VPN 및 기기 관리’에서 활성화된 다른 VPN이 있는지 확인하세요. 여러 앱의 VPN 설정을 설치해 둘 수는 있지만, 동시에 사용하는 터널과 주문형 연결 정책이 서로 영향을 줄 수 있습니다. 다른 앱의 자동 연결을 잠시 끄고 다시 테스트하되 조직에서 설치한 설정은 삭제하지 마세요. 처음 연결할 때 시스템 VPN 추가 권한을 승인하지 않았다면 앱에 준비 완료로 표시되어도 시스템 터널이 실제로 생성되지 않았을 수 있습니다.

셀룰러 네트워크에서만 실패한다면 ‘설정 → 셀룰러’에서 해당 앱의 데이터 사용 권한, 요금제 및 시스템 데이터 모드를 확인하세요. 특정 Wi-Fi에서만 실패하면 먼저 VPN을 끊고 포털 인증을 완료합니다. 네트워크를 전환한 뒤에는 기존 연결이 이전 인터페이스에 계속 묶여 있을 수 있습니다. 오래 열린 페이지를 반복해서 새로고침하기보다 클라이언트를 다시 연결하고 새 요청을 만들어 복구 여부를 확인하세요. 전환 전후 결과를 기록해 노드를 동시에 바꾸면서 비교 조건을 흐리지 마세요.

iOS의 백그라운드 동작은 데스크톱과 다릅니다. 앱 화면이 앞에 표시되지 않아도 네트워크 확장이 계속 실행될 수 있으며, 멀티태스킹 화면에서 앱 카드를 밀어 없애는 동작을 안정적인 서비스 재시작 방법으로 볼 수 없습니다. 앱 내부 연결 스위치를 사용하고 시스템 설정에서 실제 VPN 상태를 확인하세요. 기기가 뜨겁거나 배터리가 빨리 닳는다면 반복 연결, 잦은 설정 업데이트 또는 대용량 데이터를 사용하는 다른 앱이 있는지 확인하세요. 상태 표시줄에 VPN이 보인다는 이유만으로 프록시를 원인으로 단정하지 마세요.

로컬 네트워크·개인정보 보호 기능·트래픽 분기

프린터, TV 또는 로컬 네트워크 서비스에 접속할 수 없다면 해당 앱의 ‘로컬 네트워크’ 권한과 클라이언트의 로컬 네트워크 우회 규칙을 확인하세요. IP 주소로 접속하는 방식과 기기 이름을 검색하는 방식은 서로 다른 기능을 사용할 수 있습니다. IP 접속이 성공해도 멀티캐스트 검색이 작동한다는 뜻은 아닙니다. 각각 따로 테스트하고 필요한 로컬 DNS와 경로를 유지하세요. 기기 하나를 고치려고 사설 네트워크 트래픽 전체를 원격 출구로 보내지 마세요.

iCloud 비공개 릴레이와 ‘IP 주소 추적 제한’ 같은 시스템 개인정보 보호 기능은 일부 트래픽 경로를 바꿀 수 있지만 일반적인 프록시 터널과 같지는 않습니다. 충돌이 의심되면 현재 상태를 기록한 뒤 해당 옵션을 잠시 끄고 비교한 다음 테스트가 끝나면 다시 켜세요. 이 기능을 모든 연결 문제의 원인으로 간주해서는 안 됩니다. 앱 요청이 현재 클라이언트에 들어가는지, 어떤 규칙이 적용되는지, 대상이 어느 출구를 사용하는지 확인하는 것이 중요합니다.

Android 및 기기 간 설정 차이

Android에서는 다운로드 페이지 순서에 따라 Clash Plus, Clash Meta for Android, FlClash 또는 Surfboard를 선택할 수 있습니다. 백그라운드 연결이 끊기면 시스템 배터리 관리, 백그라운드 데이터 권한 및 앱 자체 VPN 설정을 확인하세요. 제조사마다 메뉴 경로가 다를 수 있습니다. 비공개 DNS, 다른 VPN 및 상시 연결 VPN 정책도 기록해야 합니다. 화면을 잠근 뒤에만 실패한다면 노드 프로토콜을 모두 바꾸기보다 먼저 백그라운드 제한을 재현해 확인하세요.

상황iOS / iPadOSAndroid
백그라운드 연결 끊김시스템 터널 상태 및 재연결 로그 확인배터리 관리 및 백그라운드 데이터 제한도 확인
DNS 오류앱 DNS 및 다른 네트워크 설정 확인비공개 DNS 및 앱 우회 규칙도 확인
네트워크 전환 실패연결을 끊었다 다시 연결한 뒤 새 요청 생성인터페이스 전환 및 VPN 자동 복구 확인
로컬 네트워크 기기를 찾을 수 없음로컬 네트워크 권한 및 우회 규칙 확인앱별 분기, 로컬 네트워크 규칙 및 검색 방식 확인

Mac, iPhone 및 iPad에서 같은 구독을 사용하더라도 실행 설정을 전부 공유할 필요는 없습니다. 데스크톱의 수신 포트, 제어 인터페이스, 파일 경로 및 보조 서비스 설정을 휴대폰에 그대로 복사하지 마세요. 노드와 필요한 규칙은 공유하고 플랫폼별 실행 옵션은 각 클라이언트에 따로 두는 것이 좋습니다. 설정 동기화 방법은 Apple 기기 설정 동기화 가이드를 참고하세요. 가져온 뒤에는 구독 이름이 같은 것만 보고 동작까지 같다고 판단하지 말고 실제 적용된 설정을 확인해야 합니다.

계속 해결되지 않으면 기기 운영체제, 현재 네트워크, 클라이언트, 선택한 정책, 접속 실패 대상 및 대략적인 발생 시간을 기록해 최소 재현 자료를 만드세요. 민감 정보를 가린 오류 요약도 함께 첨부합니다. 네트워크 설정 전체를 급하게 초기화하면 다른 연결 설정까지 삭제되어 복구 작업이 커질 수 있습니다. 설치와 연결 과정을 처음부터 다시 확인하려면 빠른 시작으로 돌아가세요. 특정 도메인이나 노드에서만 문제가 발생한다면 처음부터 모든 기기를 재설치하지 말고 이 페이지의 해당 섹션을 계속 확인하세요.