Clash 세 가지 모드 비교

먼저 터미널 요청이 어디서 막히는지 구분하세요

Git, npm, pip, Docker가 터미널에서 연결되지 않는다고 해서 곧바로 TUN 문제라고 단정할 수는 없습니다. 시스템 프록시를 따르는 프로그램은 정상인데 터미널 도구만 실패한다면 셸의 프록시 환경 변수나 도구별 설정이 원인일 수 있습니다. 반대로 브라우저와 터미널이 모두 실패하고, TUN을 켰을 때만 결과가 달라진다면 가상 인터페이스의 권한, 라우팅, DNS를 확인하세요.

TUN은 가상 네트워크 인터페이스를 통해 운영체제의 트래픽을 가로채 코어로 전달하는 기능입니다. 앱이 HTTP 프록시를 직접 사용하도록 설정하는 방식과 다르며, TUN을 활성화했다고 모든 앱의 연결이 반드시 프록시를 거치는 것은 아닙니다. 실행 모드와 규칙도 별도로 작동합니다. 예를 들어 터미널 연결이 TUN으로 코어에 들어와도 규칙에 따라 DIRECT로 나갈 수 있습니다.

TUN을 안전하게 켜고 실제 적용 여부 확인하기

먼저 클라이언트의 커널 정보 화면에서 mihomo가 사용 중인지 확인하세요. 메뉴 이름과 위치는 Clash Verge, Clash Verge Rev 등 클라이언트 버전에 따라 다를 수 있습니다. 설정을 직접 편집하기보다 클라이언트가 제공하는 TUN 스위치를 사용하고, 변경 전에는 현재 설정을 백업하세요. TUN 옵션을 불러올 수 있다고 해서 설치된 커널이 해당 설정을 모두 지원한다는 뜻은 아닙니다.

Windows: 관리자 권한과 가상 어댑터 확인

Windows에서는 TUN 인터페이스 생성과 라우팅 설정에 관리자 권한 또는 클라이언트가 설치한 보조 서비스가 필요할 수 있습니다. TUN을 켤 때 권한 요청이 표시되면 해당 클라이언트가 요청한 작업인지 확인하세요. 설정 화면에서 서비스 또는 TUN 상태가 정상인지 살펴본 다음 Windows의 「설정」→「네트워크 및 인터넷」→「고급 네트워크 설정」에서 새 가상 어댑터가 나타나는지 확인할 수 있습니다. 어댑터가 계속 생성·삭제되거나 TUN을 켠 직후 네트워크가 끊기면 클라이언트 로그와 Windows 방화벽, 다른 VPN의 가상 어댑터 충돌을 점검하세요.

macOS: 시스템 확장 승인과 VPN 충돌 확인

macOS에서는 앱이 네트워크 확장 또는 VPN 구성을 추가할 때 시스템 승인 절차가 표시될 수 있습니다. 화면에 나온 앱 이름과 요청 내용을 확인하고 운영체제의 네트워크 설정에서 해당 구성이 활성화됐는지 확인하세요. 회사 관리 기기에서는 조직 정책 때문에 네트워크 확장 승인이 제한될 수 있습니다. 다른 VPN이나 보안 도구가 동시에 가상 인터페이스와 기본 경로를 변경하는 경우에도 TUN 연결이 끊길 수 있으므로, 원인을 분리할 때는 다른 VPN을 잠시 끄고 같은 요청을 한 번씩 비교하세요.

두 운영체제 모두 TUN 상태가 “활성”이라고 표시되는 것만으로 프록시 경로가 검증되는 것은 아닙니다. 클라이언트의 연결 기록에서 해당 목적지 연결이 잡히는지, 어떤 규칙과 정책 그룹에 매칭됐는지 확인하세요. 규칙 모드라면 결과 정책이 예상한 프록시 그룹인지 살펴보고, 전역 모드라면 실제 선택된 GLOBAL 출구도 확인해야 합니다.

TUN과 별개로 터미널 프록시 설정 확인하기

셸 환경 변수는 TUN을 대체하지 않지만, HTTP 프록시를 지원하는 개발 도구의 동작을 확인하는 데 유용합니다. 아래 예시는 클라이언트에서 실제로 사용 중인 HTTP 혼합 포트가 7890일 때의 형태입니다. 포트는 설치 상태에 따라 다르므로 클라이언트의 포트 설정을 확인한 뒤 바꿔 입력하세요. SOCKS 포트와 HTTP 혼합 포트를 혼동하지 마세요.

# Bash, Zsh: 현재 터미널 세션에만 적용
export http_proxy="http://127.0.0.1:7890"
export https_proxy="http://127.0.0.1:7890"
export HTTP_PROXY="$http_proxy"
export HTTPS_PROXY="$https_proxy"

# 환경 변수 확인 및 제거
env | grep -i proxy
unset http_proxy https_proxy HTTP_PROXY HTTPS_PROXY

이 설정은 현재 셸에서 시작한 프로그램에 전달될 수 있지만, 프로그램별 구현과 대문자·소문자 변수 처리 방식은 다를 수 있습니다. 셸을 닫거나 unset을 실행하면 현재 세션의 값은 제거됩니다. 프록시 주소에 인증 정보가 필요한 경우 비밀번호를 셸 기록이나 로그에 그대로 남기지 마세요.

Git: HTTPS와 SSH를 먼저 구분

HTTPS 저장소 주소를 쓰는 Git은 HTTP 프록시 설정으로 확인할 수 있습니다. 아래 명령은 현재 저장소에만 적용하는 예시이며, 모든 저장소에 적용하려면 범위를 검토한 뒤 --global을 사용할 수 있습니다.

# 현재 저장소의 HTTPS 프록시 설정
git config http.proxy http://127.0.0.1:7890

# 설정값 확인 및 현재 저장소 설정 제거
git config --get http.proxy
git config --unset http.proxy

git@host:owner/repo.git처럼 SSH 주소를 사용하는 경우 Git의 HTTP 프록시 설정만으로 SSH 연결이 바뀌지는 않습니다. SSH 연결은 별도의 경로와 설정을 사용하므로, 먼저 HTTPS 주소로 같은 저장소에 연결해 HTTPS 전송 경로가 동작하는지 분리 테스트하세요. 인증 실패, 권한 거부와 연결 시간 초과는 서로 다른 문제입니다.

npm과 pip의 연결을 따로 진단하기

환경 변수 설정으로 npm이나 pip가 정상 동작하면 터미널에서 프록시를 읽지 못한 것이 원인이었을 수 있습니다. 환경 변수와 도구별 설정을 동시에 바꾸기보다 한 가지씩 시험하세요. npm의 현재 프록시 설정은 다음 명령으로 확인할 수 있습니다.

# npm 설정 확인
npm config get proxy
npm config get https-proxy

# 현재 사용자 설정에 프록시 지정
npm config set proxy http://127.0.0.1:7890
npm config set https-proxy http://127.0.0.1:7890

# 필요할 때 설정 제거
npm config delete proxy
npm config delete https-proxy

npm 설정은 저장 위치와 적용 범위에 따라 프로젝트별 또는 사용자별로 달라질 수 있습니다. 프로젝트에 남긴 프록시 값은 다른 네트워크에서 패키지 설치를 방해할 수 있으므로, 일시적인 테스트가 끝나면 불필요한 항목을 정리하세요. 레지스트리 주소가 사내 미러나 사용자 지정 주소라면 연결 문제와 레지스트리 설정 문제를 구분해 확인해야 합니다.

pip는 환경 변수나 설정 파일에 지정한 인덱스 주소, 프록시를 사용할 수 있습니다. 먼저 어떤 인덱스를 조회하는지 확인하고, 명령 한 번에만 프록시를 지정해 비교할 수 있습니다.

# 설정 위치와 적용 중인 값 확인
python -m pip config debug
python -m pip config list

# 명령 한 번에 프록시를 지정해 테스트
python -m pip --proxy http://127.0.0.1:7890 install 패키지이름

오류가 Could not resolve라면 DNS 확인 단계, Connection timed out라면 연결 경로와 정책을 우선 살펴보세요. 인증서 검증 오류가 발생했다면 시스템 시간, CA 인증서, 사내 HTTPS 검사 여부를 확인해야 합니다. 인증서 검증을 끄는 옵션으로 문제를 가리는 것은 안전한 해결 방법이 아닙니다.

Docker 이미지는 호스트 터미널과 별도로 확인

docker pull은 호스트의 셸에서 실행해도 Docker 데몬이 이미지 레지스트리에 연결하는 구조일 수 있습니다. 따라서 터미널의 https_proxy가 동작한다고 해서 Docker 이미지 다운로드도 같은 프록시를 자동으로 사용하는 것은 아닙니다. Docker Desktop은 별도의 가상화된 네트워크와 데몬 설정을 사용할 수 있고, Linux에서는 Docker 데몬의 서비스 설정에 프록시를 지정해야 하는 환경도 있습니다.

먼저 브라우저와 셸에서 레지스트리 도메인에 연결되는지 확인하고, 이어서 Docker Desktop의 프록시 설정 또는 Linux 데몬의 프록시 환경을 점검하세요. Linux에서 서비스를 변경했다면 설정 반영 후 Docker 데몬을 재시작해야 할 수 있습니다. 운영체제와 설치 방식에 따라 설정 위치가 다르므로, 인터넷에서 본 경로를 그대로 적용하기보다 현재 Docker 문서와 서비스 구성을 확인하세요.

오류 메시지의 단계도 구분해야 합니다. 이름 해석 실패는 DNS를, TLS 오류는 인증서와 시스템 시간 또는 검사 장비를, 인증 거부는 레지스트리 로그인과 권한을 가리킬 수 있습니다. 공개 이미지인지 비공개 이미지인지, 로그인 상태가 맞는지 확인하세요. 네트워크 문제를 해결하려고 Docker 소켓 권한을 넓히거나 인증서 검증을 비활성화하지 마세요. 그런 변경은 연결 실패와 무관하게 시스템 위험을 키울 수 있습니다.

자주 묻는 질문

TUN을 켰는데도 Git이 연결되지 않는 이유는 무엇인가요?

TUN은 트래픽을 코어로 전달하는 기능이지 모든 연결을 자동으로 프록시하는 설정은 아닙니다. 규칙 모드에서 Git 서버가 DIRECT에 매칭될 수 있고, DNS 또는 라우팅 문제로 연결이 실패할 수도 있습니다. 연결 기록에서 목적지와 매칭 규칙, 최종 정책을 확인하고 Git이 HTTPS인지 SSH인지 구분하세요.

터미널 프록시 환경 변수와 TUN을 함께 써도 되나요?

함께 사용할 수 있지만, 앱이 프록시를 직접 사용하면서 TUN 경로도 적용되는 경우에는 설정을 분석하기 복잡해질 수 있습니다. 문제 해결 중에는 TUN만 사용하는 시험과 환경 변수만 사용하는 시험을 분리하세요. 정상 경로를 확인한 다음 꼭 필요한 설정만 유지하는 것이 좋습니다.

브라우저는 되는데 Docker 이미지 다운로드만 실패하면 무엇을 확인하나요?

Docker 데몬이 호스트 브라우저나 셸과 같은 프록시 설정을 쓰는지 확인하세요. Desktop에서는 앱의 네트워크 설정, Linux에서는 데몬 서비스의 프록시 설정이 별도로 필요할 수 있습니다. 오류가 DNS, TLS, 인증 중 어느 단계인지 확인한 다음 해당 항목만 점검하세요.

클라이언트와 커널 버전은 어디서 확인하나요?

클라이언트의 정보 또는 커널 정보 화면에서 앱 버전과 mihomo 커널 버전을 각각 확인하세요. 메뉴 위치는 버전에 따라 다를 수 있습니다. TUN 관련 오류를 진단할 때는 두 버전과 운영체제 빌드, 오류 시각을 함께 기록하면 문제 범위를 좁히기 쉽습니다.