Mac에서 Clash 속도 느릴 때: 노드·경로·로컬 설정 점검

점검 시작: 로딩 지연, 다운로드 속도 저하, 간헐적 끊김 구분하기

Clash에 표시되는 노드 지연 시간은 파일 다운로드 속도와 다릅니다. 웹페이지를 열 때는 도메인 조회, 연결 설정, TLS 핸드셰이크, 콘텐츠 전송 과정을 거칩니다. 어느 단계에서든 지연이 생기면 속도가 느린 것처럼 느껴질 수 있습니다. 먼저 증상을 파악한 다음 노드, 경로, Mac 설정 순으로 범위를 좁히세요. DNS, 규칙, TUN을 한꺼번에 바꾸는 것보다 원인을 찾기 쉽습니다.

증상	우선 점검 항목	비교 방법
처음 열 때만 멈칫하고 이후에는 정상적으로 로드됨	DNS, 연결 설정, TLS 단계	같은 주소에 처음 요청했을 때와 다시 요청했을 때의 시간 비교
페이지는 열리지만 대용량 파일 다운로드가 계속 느림	노드 대역폭, 출구 혼잡, 대상 서버의 속도 제한	같은 파일을 두 개의 서로 다른 출구 노드에서 다운로드
일정한 간격으로 멈칫거림	자동 정책 전환, 네트워크 전환, 리소스 사용량	노드를 고정하고 끊김 시각과 연결 로그 기록
브라우저는 정상인데 터미널은 매우 느리거나 실패함	터미널에서 프록시를 사용하는지	명시적 프록시 옵션을 지정해 같은 주소 테스트
TUN을 켠 뒤에만 느려짐	라우팅, DNS 가로채기, 다른 네트워크 확장 프로그램	TUN을 끄고 명시적 HTTP 프록시만 사용해 비교

반복 가능한 테스트 환경 만들기

클라우드 드라이브 동기화, 시스템 업데이트, 다른 다운로드를 일시 중지하고 같은 Mac, 같은 네트워크, 같은 대상 파일을 사용합니다.
대상 요청에 실제로 적용되는 정책 그룹을 수동 선택으로 바꾸고 노드를 고정해 테스트 도중 자동 전환되지 않게 합니다.
각 테스트를 연속 3회 진행하고 시각, 노드, 네트워크 종류, 프록시 방식, 결과를 기록합니다. 첫 번째 결과는 캐시 영향을 받을 수 있으므로 따로 표시하세요.
한 번에 변수 하나만 바꾸세요. 테스트가 끝나면 설정을 원래대로 돌리고 결과가 다시 재현되는지 확인합니다.

1단계: 노드 품질과 실제 프록시 출구 확인

먼저 클라이언트의 연결 목록에서 접속 중인 도메인을 찾아 적용된 규칙, 정책 그룹, 최종 노드를 확인합니다. 화면에서 특정 노드를 선택했더라도 모든 요청이 그 노드를 거치는 것은 아닙니다. 규칙이 다른 정책 그룹을 지정하거나 DIRECT에 연결될 수 있습니다. 클라이언트마다 화면과 메뉴 위치가 다르므로 현재 사용 중인 클라이언트의 연결 세부 정보를 기준으로 확인하세요.

노드를 고정해 자동 전환 방지하기

url-test는 설정된 측정 결과에 따라 노드를 선택하고, fallback은 순서대로 사용 가능한 노드를 선택하며, load-balance는 정책에 따라 연결을 분산합니다. 문제를 확인할 때는 먼저 수동 선택 그룹을 사용해 테스트 요청이 같은 출구를 거치게 하세요. 노드를 바꿔도 이미 연결된 장기 연결은 새 노드로 이동하지 않는 경우가 많으므로 요청을 새로 시작해야 합니다. 필요한 경우 대상 앱의 기존 연결만 종료하세요.

노드 하나만 느린 경우: 해당 노드의 부하, 대역폭 제한, 상위 경로 문제를 먼저 의심하고 다른 노드로 다시 테스트하세요.
같은 지역의 여러 노드가 모두 느린 경우: 다른 지역, 다른 접속 지점, 다른 공급 경로를 비교하세요. 노드 이름만으로 경로가 독립적이라고 판단할 수는 없습니다.
모든 노드에서 특정 웹사이트만 느린 경우: 대상 사이트의 속도 제한, CDN 배정, 계정 상태, 출구 IP 접근 제한을 확인하세요.

지연 시간과 처리량 구분하기

지연 시간이 짧으면 상호작용에 유리하지만, 지속적인 다운로드 속도는 혼잡, 패킷 손실, 가용 대역폭, 원격 서버 성능에도 영향을 받습니다. 지연 시간이 더 짧은 노드라도 대용량 파일 다운로드는 느릴 수 있습니다. 테스트할 때는 정상적으로 접근 가능한 같은 파일을 사용하세요. 서로 다른 웹사이트의 다운로드 결과를 직접 비교하거나 몇 KB짜리 웹페이지로 대역폭 한계를 판단하지 마세요.

단위도 확인하세요. 다운로드 도구의 MB/s와 인터넷 회선 속도에 쓰이는 Mbps는 다릅니다. 10진 단위로 환산하면 10 MB/s는 약 80 Mbps이며, 실제 속도는 프로토콜 오버헤드의 영향을 받습니다. 이는 단위 환산일 뿐 노드 속도를 보장하는 수치는 아닙니다.

2단계: 로컬 네트워크에서 노드까지, 노드에서 대상까지의 경로 점검

프록시 연결에는 최소 두 구간이 있습니다. Mac에서 프록시 접속 지점까지, 그리고 프록시 출구에서 대상 서비스까지입니다. 노드를 바꾸면 이 중 일부 경로도 함께 바뀌므로 로컬 네트워크도 바꿔 교차 확인해야 합니다. 노드와 대상은 그대로 둔 채 휴대폰 핫스팟으로 잠시 비교해 보세요. 핫스팟에서 눈에 띄게 빨라진다면 기존 Wi-Fi, 라우터, 인터넷 서비스 제공업체의 접속 경로에 문제가 있을 가능성이 큽니다.

curl로 요청이 프록시를 거치는지 확인하기

터미널 도구가 macOS 시스템 프록시 설정을 읽는다고 단정할 수 없습니다. 아래 명령은 로컬 HTTP 포트 또는 혼합 포트를 명시하고 단계별 소요 시간을 출력합니다. 예시 포트는 127.0.0.1:7890입니다. 실행 전에 클라이언트에서 현재 사용 중인 수신 포트를 확인하세요. 입력할 주소는 다운로드가 허용된 적당한 크기의 HTTPS 파일 주소여야 합니다. 서명된 링크와 구독 링크는 공개 로그에 붙여 넣지 마세요.

printf '테스트 파일의 HTTPS 주소를 입력하세요: '
read -r TEST_URL
curl --proxy http://127.0.0.1:7890 --noproxy "" \
  --location --output /dev/null --silent --show-error \
  --connect-timeout 10 --max-time 60 \
  --write-out 'status=%{http_code}\nconnect=%{time_connect}s\ntls=%{time_appconnect}s\nfirst_byte=%{time_starttransfer}s\ntotal=%{time_total}s\nbytes=%{size_download}\nspeed=%{speed_download} B/s\n' \
  "$TEST_URL"

speed_download의 단위는 바이트/초입니다. time_starttransfer는 요청 시작부터 첫 바이트를 받을 때까지의 누적 시간이며, 서버 처리 시간만을 나타내지는 않습니다. 로컬 HTTP 프록시로 HTTPS에 접속하면 time_connect는 주로 로컬 프록시에 연결하는 시간을 반영하므로 원격 노드까지의 지연 시간으로 해석하면 안 됩니다. 이후 프록시 터널과 TLS 단계에는 원격 경로의 영향도 포함됩니다.

대상 서버에서 직접 연결을 허용한다면 프록시 옵션을 --proxy "" --noproxy "*"로 바꿔 한 차례 더 비교할 수 있습니다. 다만 이 방법은 curl의 명시적 프록시만 우회합니다. TUN이 켜져 있으면 요청이 여전히 라우팅에 가로채일 수 있습니다. 직접 연결을 제대로 비교하려면 먼저 TUN을 끄고 다른 VPN이 트래픽을 처리하지 않는지 확인하세요.

시간대별 결과로 혼잡 여부 판단하기

같은 노드가 낮에는 정상이고 저녁마다 계속 느리며 유선 연결과 Wi-Fi의 결과도 비슷하다면 공유 회선의 혼잡을 먼저 살펴볼 만합니다. 한 번 측정하는 것보다 두 시간대에 각각 3회씩 기록하는 편이 더 유용합니다. 프록시 서버에 ping을 보내도 얻을 수 있는 정보는 제한적입니다. 서버가 ICMP를 제한할 수 있고, ICMP의 경로와 우선순위가 실제 프록시 연결과 다를 수도 있습니다.

3단계: 시스템 프록시, 규칙, Mac 부하 확인

최신 macOS에서는 ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 서비스 → ‘세부사항’ → ‘프록시’에서 HTTP, HTTPS, SOCKS 설정을 확인할 수 있습니다. 시스템 버전에 따라 메뉴 이름은 조금 다를 수 있습니다. 프록시 주소가 로컬 수신 주소이고 포트가 클라이언트 설정과 일치하는지 확인한 뒤, 이전 클라이언트의 설정이 남아 있는지도 살펴보세요.

networksetup -listallnetworkservices
networksetup -getwebproxy "Wi-Fi"
networksetup -getsecurewebproxy "Wi-Fi"
scutil --proxy

네트워크 서비스 이름을 바꿨거나 USB 이더넷을 사용 중이라면 명령어의 Wi-Fi를 첫 번째 명령에서 확인한 실제 서비스 이름으로 바꾸세요. 출력에서 활성화 상태, 서버 주소, 포트를 확인하세요. 클라이언트 스위치의 색상만 보고 시스템 설정이 적용됐다고 판단하지 마세요.

중복 프록시와 규칙 오적용 확인

브라우저 프록시 확장 프로그램이 시스템 프록시 설정을 덮어쓸 수 있습니다. 테스트할 때는 확장 프로그램을 끄거나 확장 프로그램이 사용하는 출구를 분명히 기록하세요.
TUN, VPN, 트래픽 필터링 기능이 있는 도구를 두 개 이상 동시에 실행하면 라우팅 충돌이 발생할 수 있습니다. 한 번에 하나의 트래픽 처리 방식만 활성화해 확인하세요.
특정 도메인만 느리다면 연결 목록에서 원격 프록시로 잘못 연결되는지, 또는 프록시를 사용해야 하는데 직접 연결 규칙에 걸리는지 확인하세요.
‘활성 상태 보기’를 열어 CPU와 네트워크 사용량을 확인하세요. 클라이언트나 다른 프로세스가 리소스를 계속 많이 사용한다면 백그라운드 작업을 멈춘 뒤 같은 요청을 다시 테스트하세요.

Clash는 코어와 클라이언트 생태계에서 쓰이는 이름이며, 모든 그래픽 클라이언트가 같은 설정 덮어쓰기, 로그, 서비스 모드를 제공하는 것은 아닙니다. mihomo를 사용하는 클라이언트도 권한 관리와 설정 병합 방식이 다를 수 있습니다. 수정 전에 구독 파일의 원본 YAML만 보지 말고 실제 적용된 설정을 확인하세요. 필드의 의미는 YAML 매뉴얼에서 확인할 수 있습니다.

DNS 모드: 첫 로딩 지연과 DNS 조회 오류 확인

DNS 문제는 처음 열 때만 느리거나 일부 도메인이 열리지 않는 경우, 브라우저와 명령줄 결과가 다른 경우로 나타날 수 있습니다. mihomo의 fake-ip 모드는 도메인에 매핑 주소를 할당하고, redir-host 모드는 실제 조회 결과를 사용합니다. 둘 중 하나가 무조건 빠르거나 느린 것은 아닙니다. 앱, 라우팅 방식, DNS 설정에 따라 호환성이 달라집니다.

먼저 DNS 조회 경로 확인하기

scutil --dns를 실행해 현재 시스템의 리졸버와 적용 범위를 확인하세요. VPN과 네트워크 인터페이스마다 별도의 리졸버가 설정될 수 있습니다.
브라우저에서 별도의 보안 DNS를 사용 중인지 확인하세요. 브라우저에서 DNS 조회가 정상이라고 해서 시스템 리졸버나 클라이언트 내장 DNS도 정상이라는 뜻은 아닙니다.
클라이언트 로그에서 DNS 시간 초과, 상위 DNS 서버 연결 실패, 반복 재시도를 확인하세요. 상위 DNS 서버가 아직 연결되지 않은 프록시에 의존하면 시작 단계에서 의존성 문제가 발생할 수 있습니다.
영향을 받은 도메인 하나만 반복 테스트한 뒤 네트워크를 바꾸기 전과 후의 결과를 비교하세요. 모든 상위 DNS 서버와 모드를 한꺼번에 바꾸지 마세요.

HTTP 프록시로 HTTPS에 접속하면 대상 도메인의 조회를 보통 프록시 서버가 처리합니다. 따라서 curl에서 측정한 로컬 DNS 조회 시간만으로 대상 도메인의 DNS 성능을 판단할 수 없습니다. 마찬가지로 dig가 기본으로 사용하는 조회 경로도 브라우저, 시스템 DNS API, mihomo 내부 조회 경로와 다를 수 있습니다.

TUN 스택과 Wi-Fi 절전: 변수 하나씩 검증하기

TUN 스택 선택과 라우팅 확인

TUN은 가상 네트워크 인터페이스를 통해 IP 트래픽을 처리하며 노드 대역폭을 직접 늘려 주지는 않습니다. mihomo에서 제공하는 스택 옵션은 system, gvisor, mixed입니다. 실제 사용 가능 여부와 기본값은 클라이언트에 포함된 코어 및 해당 문서를 기준으로 확인하세요. 스택마다 프로토콜 처리 방식, 호환성, 리소스 사용량이 달라 모든 Mac에 맞는 단일 최적 설정은 없습니다.

현재 스택을 기록한 다음 스택 옵션만 바꾸고, 클라이언트 안내에 따라 TUN을 다시 활성화하거나 코어를 재시작한 뒤 같은 요청을 다시 테스트하세요. 아래는 비교할 필드만 보여 주는 예시이며 완전한 설정 파일이 아닙니다. 기존 TUN, DNS, 라우팅, 권한 설정을 덮어쓰는 데 사용하지 마세요.

tun:
  enable: true
  stack: system

명시적 HTTP 프록시에서는 정상인데 TUN에서 문제가 생긴다면 라우팅 루프, DNS 가로채기, 다른 네트워크 확장을 중점적으로 확인하세요. 처음부터 MTU를 임의로 조정하지 마세요. 특정 대상에 큰 데이터를 전송할 때 멈추거나 핸드셰이크 후 진행되지 않는 등 근거가 있을 때만 코어 문서를 참고해 항목별로 비교하세요. 자동 라우팅을 켜기 전에는 로컬 네트워크 기기와 업무용 VPN에 접근해야 하는지도 확인해야 합니다.

Wi-Fi 간섭과 저전력 모드 구분하기

Mac의 저전력 모드는 ‘프록시 속도 제한 스위치’가 아니므로 이것만으로 Clash 다운로드 속도 저하를 단정할 수 없습니다. 다만 테스트 변수로 활용할 수는 있습니다. ‘시스템 설정’ → ‘배터리’에서 저전력 모드를 확인하고 전원 어댑터를 연결한 뒤, 같은 장소와 노드에서 각각 결과를 기록하세요. 메뉴 이름과 사용 가능 여부는 기종과 시스템 버전에 따라 달라질 수 있으며 한 번 바꿨다는 이유만으로 원인이라고 단정해서는 안 됩니다.

Option 키를 누른 채 메뉴 막대의 Wi-Fi 아이콘을 클릭하면 시스템이 제공하는 신호, 노이즈, 전송 속도 정보를 볼 수 있습니다. 이는 무선 링크 상태 지표이지 인터넷 다운로드 속도는 아닙니다.
라우터 가까이에서 다시 테스트하고, 가능하다면 유선 연결과 비교하세요. 유선은 정상인데 Wi-Fi만 느리다면 신호, 간섭, 로밍 문제부터 살펴보세요.
5GHz와 2.4GHz 네트워크를 각각 테스트하세요. 벽이 많은 환경에서는 5GHz가 항상 더 안정적인 것은 아니므로 현재 위치에서 반복 측정한 결과로 판단하세요.
잠자기 모드에서 깨어난 뒤에만 느려진다면 Wi-Fi를 다시 연결하고 클라이언트의 프록시 및 TUN 상태를 확인하세요. 문제를 가리기 위해 클라이언트를 반복해서 재설치하지 마세요.

결과 분류와 설정 복원

문제 해결의 목표는 설정을 이것저것 바꾸는 것이 아니라 재현 가능한 결론을 얻는 것입니다. 예를 들어 ‘같은 노드와 파일에서 유선은 정상인데 Wi-Fi는 계속 느리다’면 무선 네트워크에 초점을 맞출 수 있습니다. ‘TUN을 끄면 명시적 프록시는 정상이다’라면 Mac의 트래픽 처리 경로로 범위를 좁힐 수 있습니다. 결론이 구체적일수록 추측에 의존하지 않고 다음 조치를 정하기 쉽습니다.

노드 문제: 출구를 바꾸고 서비스 제공업체에 발생 시각, 노드, 대상 정보를 전달하세요. 계정 정보, 구독 주소, 인증 매개변수는 가려야 합니다.
경로 문제: 접속 네트워크와 시간대별 비교 결과를 보관해 로컬 접속 구간의 혼잡인지 출구에서 대상까지의 문제인지 구분하세요.
Mac 문제: 효과를 확인한 변경만 유지하고 임시로 바꿨던 스택, DNS, 정책 그룹, 절전 설정은 원래대로 복구하세요.
원인을 찾기 어려운 경우: 클라이언트 이름, 코어 종류, macOS 환경, 프록시 방식, 민감 정보를 가린 로그를 제공하세요. 지연 시간 스크린샷만 보내는 것은 피하세요.

클라이언트를 바꿔 보면 GUI 설정이나 권한 차이를 확인하는 데 도움이 될 수 있지만 구독 노드의 용량까지 자동으로 바뀌지는 않습니다. 먼저 병목이 어디인지 확인한 뒤 규칙을 조정할지, 로컬 설정을 고칠지, 출구 경로를 바꿀지 결정하세요.