시스템 프록시를 켰는데도 우회되지 않을 때: 브라우저·터미널별 점검

먼저 구분하기: 커널에 요청이 전달되지 않는가, 규칙이 직접 연결을 선택하는가

‘시스템 프록시’는 운영체제에 프록시 주소와 포트를 등록하는 설정일 뿐, 기기의 모든 트래픽을 Clash로 보내는 기능은 아닙니다. 이 설정을 따르는지는 앱이 사용하는 네트워크 구성 요소에 따라 달라집니다. 브라우저 확장 프로그램이나 앱 자체 프록시 설정, 터미널 환경 변수도 실제 연결 경로에 영향을 줄 수 있습니다.

자주 발생하는 또 다른 오해는 요청이 이미 mihomo 커널에 전달됐지만 규칙에 따라 DIRECT로 연결되는 경우입니다. 이때 외부 IP가 바뀌지 않는 것은 규칙의 결과이지 시스템 프록시가 작동하지 않는다는 뜻이 아닙니다. 먼저 클라이언트의 ‘연결’ 페이지를 열고 대상 도메인으로 필터링한 다음, 일치한 규칙과 정책 그룹, 최종 아웃바운드를 확인하세요.

확인된 증상	우선 확인할 항목	다음 단계
연결 페이지에 대상 요청이 표시되지 않음	앱이 프록시를 사용하는지 여부	브라우저 설정을 확인하거나 프록시를 직접 지정
요청은 표시되지만 최종 아웃바운드가 DIRECT	규칙 순서와 정책 그룹 선택	해당 도메인이 원래 직접 연결 대상인지 확인
요청이 프록시 그룹에 전달됐지만 연결 시간 초과	노드, 대상 사이트, 네트워크 연결 상태	정상 작동이 확인된 다른 노드로 비교
프록시를 직접 지정하면 성공하지만 일반 접속은 실패	시스템 프록시 연결 단계	브라우저와 터미널을 나눠 점검

1단계: 프록시를 직접 지정해 로컬 수신 포트 확인

우선 규칙, 구독, DNS는 변경하지 마세요. 같은 대상 주소에 프록시를 직접 지정해 요청을 보내고, 커널이 요청을 받을 수 있는지 따로 확인합니다. Windows PowerShell에서는 curl.exe를 사용하세요. Windows PowerShell 5.1의 curl 별칭이 인수 처리에 영향을 줄 수 있습니다. macOS와 Linux에서는 curl을 사용하면 됩니다.

# Windows PowerShell
curl.exe -v --connect-timeout 10 --max-time 20 --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/ -o NUL

# macOS / Linux
curl -v --connect-timeout 10 --max-time 20 --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/ -o /dev/null

--noproxy ""는 이번 테스트에서 우회 목록을 비워 기존 NO_PROXY 설정이 결과를 방해하지 않도록 합니다. 상세 출력에서 127.0.0.1:7890에 연결되는지, HTTPS 요청의 CONNECT 터널이 만들어지는지 확인하세요. 동시에 클라이언트의 ‘연결’ 또는 ‘로그’에서 해당 기록을 찾습니다.

즉시 연결 거부가 표시됨: 커널이 실행 중인지, 포트를 잘못 입력하지 않았는지, 수신 주소에 IPv4 루프백 주소가 포함됐는지 확인하세요.
로컬 포트에는 연결되지만 CONNECT 이후 실패함: 노드, 규칙, TLS 또는 대상 사이트의 접속 가능 여부를 확인하세요. 시스템 프록시 스위치만 반복해서 켜고 끄지는 마세요.
HTTP 407 응답이 표시됨: 로컬 프록시 인증 설정을 확인하세요. 비밀번호가 포함된 전체 명령을 공개 로그에 붙여 넣지 마세요.
대상 사이트의 HTTP 응답을 받음: 이번 요청이 로컬 프록시를 통해 전달됐다는 뜻입니다. 원격 노드를 거쳤는지는 클라이언트의 아웃바운드 기록으로 확인하세요.

Windows에서는 Get-NetTCPConnection -State Listen -LocalPort 7890을 실행해 수신 상태를 확인할 수 있습니다. macOS에서는 lsof -nP -iTCP:7890 -sTCP:LISTEN을 실행하세요. 다른 프로그램이 포트를 사용 중이라면 먼저 어떤 프로세스인지 확인한 뒤, 충돌하는 프로그램을 종료하거나 클라이언트 포트를 변경하세요.

브라우저 점검: 시스템 설정, 확장 프로그램, 개별 설정

Chrome·Edge: 먼저 확장 프로그램이 프록시를 가로채는지 확인

클라이언트에서 ‘시스템 프록시’를 켜고 구독이 활성화됐는지, 현재 정책 그룹에서 사용 가능한 노드를 선택했는지 확인하세요.
Chrome에서는 ‘설정’ → ‘시스템’ → ‘컴퓨터 프록시 설정 열기’를 선택하세요. Edge에서는 ‘설정’ → ‘시스템 및 성능’에서 컴퓨터 프록시 설정 메뉴를 찾으면 됩니다. 메뉴 문구는 버전에 따라 다를 수 있습니다.
Windows 11에서는 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’로 이동하세요. Windows 10에서도 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’를 선택하면 됩니다. 수동 프록시의 주소와 포트가 클라이언트 설정과 일치하는지 확인하세요.
chrome://extensions/ 또는 edge://extensions/를 열고 프록시를 제어하는 확장 프로그램을 일시적으로 사용 중지하세요. 프록시 설정을 자동으로 전환하는 확장 프로그램도 포함됩니다.
브라우저를 완전히 종료한 뒤 다시 실행하고, 같은 테스트 주소에 접속해 클라이언트 연결 기록을 확인하세요.

시크릿 창만으로는 충분히 분리해 테스트할 수 없습니다. 확장 프로그램이 시크릿 모드에서 허용됐을 수 있고 시스템 설정도 계속 적용되기 때문입니다. 프록시 확장 프로그램을 설정하지 않은 새 브라우저 프로필을 만들어 비교하는 편이 더 확실합니다. ‘조직에서 관리함’이라는 안내가 표시되면 chrome://policy/ 또는 edge://policy/도 확인하세요. 관리되는 기기의 정책은 관리자에게 변경을 요청해야 합니다.

Firefox: 프록시 설정 출처를 직접 선택

Firefox에서 ‘설정’ → ‘일반’ → ‘네트워크 설정’ → ‘설정’을 여세요. 클라이언트가 등록한 시스템 프록시를 사용하려면 ‘시스템 프록시 설정 사용’을 선택합니다. ‘수동 프록시 설정’을 사용한다면 HTTP 프록시 주소와 포트, HTTPS 프록시 옵션을 직접 관리해야 합니다. 시스템 프록시를 켜도 기존 SOCKS 설정이 자동으로 비활성화되지는 않습니다.

macOS에서는 ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 연결 → ‘세부사항’ → ‘프록시’에서 웹 프록시와 보안 웹 프록시를 확인할 수 있습니다. Linux 데스크톱의 프록시 설정을 앱이 따르는지는 데스크톱 환경과 앱의 구현에 따라 다릅니다. 데스크톱의 스위치만 보고 모든 브라우저에 적용됐다고 판단하지 마세요.

터미널 점검: HTTP_PROXY와 HTTPS_PROXY 설정

터미널 프로그램은 대개 데스크톱의 시스템 프록시를 자동으로 사용하지 않습니다. curl, Git, 패키지 관리자도 각자의 설정 파일을 읽을 수 있습니다. 브라우저에서는 접속되지만 터미널에서 실패한다면, 우선 시스템 전체 설정을 바꾸지 말고 현재 터미널 세션에 환경 변수를 설정하세요.

Windows PowerShell: 현재 세션에만 적용

$env:HTTP_PROXY = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"
$env:NO_PROXY = "localhost,127.0.0.1,::1"

curl.exe -v --connect-timeout 10 --max-time 20 https://example.com/ -o NUL

# 테스트가 끝나면 이번 설정을 삭제
Remove-Item Env:HTTP_PROXY, Env:HTTPS_PROXY, Env:NO_PROXY -ErrorAction SilentlyContinue

HTTPS_PROXY는 HTTPS 대상 요청에 사용할 프록시를 지정하는 변수이지, 로컬 프록시 주소를 반드시 https://로 써야 한다는 뜻은 아닙니다. 일반적인 HTTP 또는 혼합 수신 포트에는 http://127.0.0.1:7890을 사용하고, CONNECT를 통해 HTTPS 연결을 전달합니다.

macOS·Linux: 환경 변수의 대소문자에 유의

export http_proxy="http://127.0.0.1:7890"
export https_proxy="http://127.0.0.1:7890"
export no_proxy="localhost,127.0.0.1,::1"

curl -v --connect-timeout 10 --max-time 20 https://example.com/ -o /dev/null

# 테스트가 끝나면 이번 설정을 삭제
unset http_proxy https_proxy no_proxy

대소문자를 구분하는 환경에서 curl은 HTTP 프록시 변수로 소문자 http_proxy만 지원합니다. 다른 프로그램은 변수 처리 방식이 다를 수도 있습니다. 먼저 위의 최소 설정으로 확인한 뒤, 대상 도구의 문서에 따라 대문자 변수를 설정하세요. 기존 프록시 변수가 있다면 원래 값을 기록해 두고 테스트 후 복원하세요. 기존에 사용 중인 설정을 바로 삭제하지 마세요.

환경 변수는 현재 프로세스와 이후에 시작되는 자식 프로세스에만 적용됩니다. 이미 열려 있는 IDE 터미널, 백그라운드 작업, 시스템 서비스에는 자동으로 반영되지 않습니다. 설정을 유지해야 한다면 해당 셸의 시작 파일에 추가하고 터미널을 다시 열어 확인하세요. 프록시를 끈 뒤에도 작동하지 않는 고정 주소가 남지 않도록 주의하세요.

앱별 설정: Git, SOCKS, 격리된 환경

Git: 남아 있는 프록시 설정부터 확인하고 전역 설정은 덮어쓰지 않기

Git의 HTTP 전송은 환경 변수와 Git 설정의 영향을 모두 받을 수 있습니다. 설정 출처를 먼저 확인해 이전 포트, 원격 프록시 주소, URL별 설정이 남아 있는지 살펴보세요. 출력에 인증 정보가 포함될 수 있으므로 공유하기 전에 민감한 내용을 가리세요.

git config --show-origin --get-regexp '.*proxy.*'

# 이번 Git 명령에만 프록시 지정
git -c http.proxy=http://127.0.0.1:7890 ls-remote https://github.com/git/git.git HEAD

두 번째 명령은 Git의 HTTPS 접속 경로만 확인하며 전역 설정을 변경하지 않습니다. git@으로 시작하는 SSH 저장소 주소는 별도의 전송 경로이므로 http.proxy를 설정해도 자동으로 HTTP 프록시를 거치지 않습니다.

SOCKS: 로컬 DNS 조회와 프록시 측 DNS 조회 구분

클라이언트에서 SOCKS 수신 포트만 제공한다면 이를 HTTP 포트처럼 사용할 수 없습니다. SOCKS 포트가 7891이라고 확인된 경우 아래 명령을 실행하세요. 혼합 포트를 사용한다면 실제 혼합 포트 값으로 바꿔야 합니다.

curl --proxy socks5h://127.0.0.1:7891 --noproxy "" --connect-timeout 10 --max-time 20 https://example.com/

curl의 socks5h://는 대상 도메인의 조회를 SOCKS 프록시 쪽에서 수행합니다. socks5://는 일반적으로 로컬에서 먼저 조회합니다. 이 차이는 로컬 DNS 문제를 구분하는 데 도움이 되지만, 모든 앱의 DNS 요청이 프록시로 전달된다는 뜻은 아닙니다.

WSL, 컨테이너, 가상 머신에는 주소 경계 문제도 있습니다. 내부의 127.0.0.1이 호스트를 가리키지 않을 수 있습니다. WSL은 NAT와 미러링 네트워크 모드의 동작이 다르므로 실제 모드에 맞춰 호스트 주소를 확인하세요. 네트워크 경계를 넘어 수신 포트에 접근해야 한다면 ‘LAN 연결 허용’, 수신 주소, 방화벽 범위를 함께 검토하세요. 프록시 포트를 공용 네트워크에 그대로 노출하지 마세요.

TUN 모드: 프록시 설정을 사용하지 않는 앱 처리

앱이 시스템 프록시를 따르지 않고 프록시를 직접 지정하는 기능도 없다면, mihomo 클라이언트의 TUN 모드를 고려할 수 있습니다. TUN은 가상 네트워크 인터페이스와 라우팅을 통해 IP 트래픽을 전달하므로 HTTP 시스템 프록시와는 다른 계층에서 연결을 처리합니다. 브라우저가 ‘시스템 설정을 더 강제로 따르게’ 하는 기능은 아닙니다.

먼저 프록시를 직접 지정해 노드, 구독, 규칙이 정상인지 확인한 다음 현재 설정을 내보내고 복구용 사본을 보관하세요.
클라이언트의 ‘설정’에서 ‘서비스 모드’를 찾아 안내에 따라 서비스를 설치하거나 활성화하세요. 일부 클라이언트는 다른 권한 상승 방식을 사용하므로 현재 버전의 화면을 기준으로 진행하면 됩니다.
‘TUN 모드’를 켜고 로그에서 가상 인터페이스와 라우팅이 정상적으로 구성됐는지 확인하세요. auto-route, DNS 처리, 인터페이스 감지 설정은 클라이언트가 생성한 구성과 일치해야 합니다.
기본 경로 충돌을 방지하려면 먼저 다른 VPN이나 가상 네트워크 어댑터의 트래픽 처리 기능을 끄세요. 그런 다음 브라우저, 터미널, LAN 기기, 내부 사이트에 접속해 확인합니다.
네트워크가 끊기면 먼저 TUN을 끈 다음 기존 시스템 프록시 설정을 복원하세요. 문제가 발생한 상태에서 DNS, 라우팅, 규칙을 한꺼번에 다시 작성하지 마세요.

TUN이 특정 앱의 트래픽을 처리하는지는 라우팅, 제외 항목, 네트워크 인터페이스, 권한에 따라 달라집니다. UDP, QUIC 등의 트래픽이 정상적으로 전달되는지도 커널 설정과 노드 기능에 좌우됩니다. TUN을 켜도 규칙이 DIRECT를 선택할 수 있습니다. ‘TUN으로 유입되는 것’과 ‘최종적으로 원격 노드를 거치는 것’은 별개의 판단입니다.

재테스트 순서: 한 번에 변수 하나씩 변경

점검을 마친 뒤 같은 대상, 같은 노드, 같은 규칙 모드로 비교하세요. 웹페이지가 열리는지 또는 외부 IP 조회 한 번의 결과만으로 판단하지 마세요. 캐시, 우회 목록, 대상 도메인의 분기 규칙에 따라 결과가 달라질 수 있습니다.

로컬 연결: 127.0.0.1:7890을 직접 지정했을 때 클라이언트에 해당 요청이 기록되는지 확인합니다.
브라우저: 프록시 확장 프로그램을 끄고 프록시 설정 출처를 확인한 뒤 연결 기록이 표시되는지 봅니다.
터미널: 현재 세션에 환경 변수를 설정한 뒤 대상 도구에서 같은 요청을 성공적으로 보낼 수 있는지 확인합니다.
아웃바운드 선택: 요청에 실제로 어떤 규칙이 적용됐는지, 정책 그룹에서 최종적으로 어떤 노드를 선택했는지 확인합니다.
복원 확인: 클라이언트를 종료한 뒤 터미널 프록시 변수를 제거해야 하는지 확인합니다. TUN을 끈 뒤 내부망 접속과 DNS가 정상으로 돌아왔는지도 점검하세요.

문제 기록을 제출할 때는 운영체제 버전, 클라이언트와 커널 버전, 실제 수신 포트, 실패한 명령, 발생 시각, 관련 로그 일부를 포함하세요. 구독 주소, 인증 정보, 민감한 도메인은 삭제해야 합니다. 규칙과 DNS를 더 확인하려면 문제 해결 가이드를 참고하세요. 시스템 프록시, 정책 그룹, TUN의 차이는 용어 빠른 안내에서 확인할 수 있습니다.