시스템 프록시가 작동하지 않을 때 확인할 사항

먼저 구분하기: 프록시 설정, 앱의 연결 경로, 규칙에 따른 출구

Clash 클라이언트에 “시스템 프록시가 켜짐”이라고 표시되어도, 보통은 운영체제 설정에 로컬 프록시 주소를 기록하려고 시도했다는 뜻일 뿐입니다. 모든 프로그램이 코어를 거치거나 모든 요청이 원격 노드를 사용하는 것은 아닙니다. 브라우저는 시스템 설정을 따를 수도 있고 확장 프로그램이 프록시를 가로챌 수도 있습니다. 터미널의 curl, Git, 패키지 관리자 등은 각자 환경 변수나 설정 파일을 사용할 수 있습니다.

요청은 세 단계를 차례로 거칩니다. 앱이 로컬 수신 포트에 연결하고, 코어가 규칙에 따라 정책을 선택한 뒤, 선택된 출구가 연결을 완료합니다. 문제를 확인할 때는 테스트 URL과 포트를 고정한 다음 클라이언트의 ‘연결’ 화면이나 로그를 확인하세요. 노드를 바꾸고 DNS를 수정하고 TUN을 켜는 작업을 동시에 하지 마세요. 어떤 변경이 효과가 있었는지 알 수 없습니다.

1단계: 코어가 로컬 포트를 실제로 수신 중인지 확인

mixed-port, port, socks-port 구분하기

mihomo 설정의 mixed-port는 같은 포트에서 HTTP와 SOCKS 프록시 요청을 모두 받을 수 있습니다. port는 HTTP 프록시 진입점이고, socks-port는 SOCKS 진입점입니다. SOCKS만 지원하는 포트에 HTTP 요청을 보내면 프로토콜 오류가 발생하거나 연결이 끊길 수 있습니다. GUI 클라이언트가 구독 설정의 포트를 덮어쓸 수도 있으므로 구독 원문보다 실행 중인 설정을 확인하는 편이 정확합니다.

# mihomo 로컬 진입점 설정 예시입니다. 구독 설정 전체를 그대로 덮어쓰지 마세요
mixed-port: 7890
allow-lan: false
mode: rule

같은 컴퓨터에서 실행하는 브라우저와 터미널에는 allow-lan을 켤 필요가 없습니다. 이 옵션은 LAN 접근을 제어하며, 로컬 앱이 시스템 프록시를 사용하게 하는 설정이 아닙니다. 로컬 연결을 확인할 때는 명시적인 IPv4 루프백 주소 127.0.0.1을 사용하세요. localhost가 ::1로 해석되지만 코어는 IPv4에서만 수신하는 상황을 피할 수 있습니다.

수신 포트를 확인한 다음 프록시를 명시해 요청 보내기

# Windows PowerShell: 7890 포트의 수신 상태 확인
Get-NetTCPConnection -LocalPort 7890 -State Listen

# Linux: TCP 수신 포트 확인
ss -lntp 'sport = :7890'

# macOS: TCP 수신 포트와 프로세스 확인
lsof -nP -iTCP:7890 -sTCP:LISTEN

운영체제에 맞는 명령 하나만 실행하면 됩니다. 수신 결과가 없다면 클라이언트 코어가 시작되지 않았거나 설정을 파싱하지 못했거나 포트가 이미 사용 중인 문제부터 해결하세요. 수신 중으로 표시되더라도 해당 프로세스를 확인해야 합니다. 다른 프로그램이 7890 포트를 사용 중일 수도 있습니다.

# macOS / Linux
curl -q -v --noproxy "" --proxy http://127.0.0.1:7890 \
  --connect-timeout 7 --max-time 20 -I https://example.com/

# Windows PowerShell: curl.exe를 명시적으로 사용
curl.exe -q -v --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 7 --max-time 20 -I https://example.com/

-q를 첫 번째 인수로 지정하면 기본 curl 설정 파일을 건너뜁니다. 빈 인수를 전달할 수 있는 셸에서 --noproxy ""를 사용하면 프록시 우회 목록을 비울 수 있으며, --proxy로 진입점을 명시합니다. 구버전 Windows PowerShell은 빈 문자열 인수를 전달하는 방식이 다를 수 있습니다. 결과에 여전히 프록시 우회가 표시되면 현재 세션의 NO_PROXY를 임시로 제거한 뒤 다시 시도하세요.

Connected to 127.0.0.1이 표시되면 로컬 프록시 진입점에 연결할 수 있다는 뜻입니다. HTTPS 요청에서 이어서 200 Connection established가 표시되면 HTTP CONNECT 터널이 만들어진 것입니다. 그다음 대상 사이트의 응답과 코어 연결 기록도 확인하세요. 여기서는 example.com을 테스트하므로 성공해도 모든 사이트에 접근할 수 있다는 뜻은 아닙니다.

2단계: 브라우저의 시스템 설정과 확장 프로그램을 따로 확인

Chrome·Edge: 먼저 확장 프로그램의 프록시 가로채기 확인

1. Chrome에서 chrome://extensions/를, Edge에서 edge://extensions/를 열고 프록시, PAC 또는 네트워크 전환을 관리하는 확장 프로그램을 모두 잠시 사용 중지하세요.
2. Chrome에서는 ‘설정’ → ‘시스템’ → ‘컴퓨터의 프록시 설정 열기’로 이동하세요. Edge에서는 ‘설정’ → ‘시스템 및 성능’ → ‘시스템’에서 프록시 설정으로 이동하세요. 버전에 따라 메뉴 이름과 위치가 조금 다를 수 있습니다.
3. 시스템 프록시 설정에서 주소, 포트, 우회 목록을 확인하세요. 시스템에서 PAC를 사용한다면 현재 적용된 설정이 PAC인지 수동 프록시인지 확인하세요. 특정 토글 하나만 보고 실제 연결 경로를 판단하지 마세요.
4. 브라우저를 완전히 종료한 뒤 다시 실행하고 테스트 사이트에 접속하면서 클라이언트의 연결 기록을 확인하세요.

Windows 11에서는 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’에서 설정합니다. macOS에서는 ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 서비스 → ‘세부사항’ → ‘프록시’로 이동하세요. 수동 HTTP 프록시와 보안 웹 프록시가 별도 항목일 수 있으므로 HTTPS 사이트를 테스트할 때는 해당 설정도 확인해야 합니다.

설정 페이지에 프록시가 확장 프로그램이나 조직에서 관리한다고 표시되면 먼저 관리 주체를 확인하세요. 기업 정책이나 브라우저 시작 매개변수가 일반 설정을 덮어쓸 수 있습니다. Clash의 시스템 프록시 버튼을 반복해서 켜고 꺼도 이 문제는 해결되지 않는 경우가 많습니다. 일부 확장 프로그램은 비공개 창에서도 실행할 수 있으므로 비공개 창 테스트만으로 문제가 분리되지는 않습니다.

Firefox: 별도 프록시 설정 여부 확인

데스크톱 Firefox에서 ‘설정’ → ‘일반’ → 페이지 아래쪽의 ‘네트워크 설정’ → ‘설정’으로 이동하세요. ‘시스템 프록시 설정 사용’을 선택해야 운영체제의 프록시를 따릅니다. ‘수동 프록시 설정’이나 ‘자동 프록시 구성 URL’을 선택하면 브라우저 자체 설정을 사용합니다.

• 수동 HTTP 프록시: 주소에 127.0.0.1, 포트에 실제 HTTP 포트나 혼합 포트를 입력하세요. HTTPS 프록시 항목도 확인해야 합니다.
• 수동 SOCKS 설정: SOCKS v5를 선택하고 SOCKS 포트나 혼합 포트를 입력하세요. 대상 도메인 해석도 프록시에서 처리해야 한다면 SOCKS v5의 프록시 DNS 옵션을 확인하세요.
• ‘프록시 사용 안 함’ 목록에 테스트 도메인이나 해당 도메인의 접미사가 있는지 확인하세요. 우회 규칙을 클라이언트 오류로 오인할 수 있습니다.

3단계: 현재 터미널 세션에 프록시 환경 변수 설정

터미널 창 자체가 네트워크 요청을 프록시 처리하는 것은 아닙니다. 실제 연결은 터미널에서 실행하는 프로그램이 시작합니다. 많은 명령줄 도구는 데스크톱의 시스템 프록시를 자동으로 읽지 않습니다. 프록시를 명시한 테스트는 성공하지만 일반 명령이 실패한다면 노드부터 바꾸지 말고 해당 도구가 지원하는 환경 변수를 설정하세요.

macOS·Linux: 먼저 임시로 export 설정

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 7 --max-time 20 -I https://example.com/

https_proxy라는 변수 이름은 HTTPS 대상에 사용할 프록시라는 뜻이지, 변수 값에 https://를 써야 한다는 뜻은 아닙니다. 일반적인 Clash 로컬 HTTP 프록시는 HTTP CONNECT로 HTTPS를 전달하므로 여기에는 http://127.0.0.1:7890을 사용합니다. 이를 임의로 https://로 바꾸면 도구가 로컬 프록시와 TLS 연결을 시도해 수신 포트가 이를 지원하지 않을 경우 실패할 수 있습니다.

이 변수는 현재 셸과 이후 실행되는 하위 프로세스에만 영향을 줍니다. 적용을 확인한 뒤 실제로 사용하는 셸에 맞춰 ~/.zshrc 또는 ~/.bashrc에 추가하세요. 시작 파일 여러 개에 한꺼번에 넣지 마세요. 데스크톱에서 실행한 IDE는 해당 파일을 읽지 않을 수 있으므로 IDE의 환경 변수나 터미널 설정도 따로 확인해야 합니다.

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 7 --max-time 20 -I https://example.com/

Windows PowerShell 5.1에서 curl은 Invoke-WebRequest의 별칭일 수 있습니다. curl.exe를 사용하면 curl을 명시적으로 실행해 두 도구의 매개변수와 프록시 동작을 혼동하지 않을 수 있습니다. 세션 변수는 이미 실행 중인 프로그램에 소급 적용되지 않으며, 새 프로세스를 시작할 때 현재 환경을 상속합니다.

SOCKS를 사용할 때는 DNS 조회 위치를 명확히 확인

curl -q -v --noproxy "" --proxy socks5h://127.0.0.1:7890 \
  --connect-timeout 7 --max-time 20 -I https://example.com/

curl에서 socks5://는 보통 로컬에서 대상 도메인을 조회하고, socks5h://는 대상 도메인 조회를 SOCKS 프록시에 맡깁니다. 이 차이를 활용해 DNS 문제를 확인할 수 있지만 다른 도구가 같은 URL 형식을 지원한다고 단정할 수는 없습니다. ALL_PROXY를 설정하기 전에 해당 도구의 문서를 확인하세요. 모든 프로그램에 적용되는 것은 아닙니다.

4단계: NO_PROXY와 도구별 설정 확인

환경 변수가 올바른데도 직접 연결된다면 우회 목록이나 도구별 설정이 원인일 수 있습니다. NO_PROXY와 no_proxy는 프록시를 거치지 않을 호스트를 지정합니다. 대소문자, 도메인 접미사, CIDR 지원 여부는 도구마다 다릅니다. 특히 *가 있는지 확인하세요. 많은 도구에서 모든 대상에 대한 프록시 우회를 뜻합니다.

# macOS / Linux: 로컬 프록시 변수만 확인
env | grep -i proxy

# Windows PowerShell
Get-ChildItem Env: | Where-Object Name -Match 'proxy'

# 시스템, 전역, 현재 저장소의 Git 설정 출처 확인
git config --show-origin --get-regexp '.*proxy.*'

Git의 http.proxy, URL별 프록시 설정, 패키지 관리자의 자체 프록시 설정 때문에 같은 터미널에서 실행한 명령도 서로 다른 경로를 사용할 수 있습니다. Git이 예전 주소인 127.0.0.1:7891을 가리키는데 현재 클라이언트는 7890만 수신한다면 curl은 성공하고 Git은 실패할 수 있습니다.

• Git: --show-origin으로 구체적인 설정 파일과 적용 범위를 확인한 뒤 오류가 확인된 항목만 수정하세요. 저장소별 설정이 전역 설정을 덮어쓸 수 있습니다.
• npm: npm config get proxy와 npm config get https-proxy로 도구 자체의 프록시 진입점을 확인하고 프로젝트의 .npmrc도 살펴보세요.
• WSL 및 컨테이너: 내부의 127.0.0.1은 보통 각자의 네트워크 환경을 가리키며 Windows나 호스트를 의미한다고 볼 수 없습니다. WSL 네트워크 모드와 컨테이너 네트워크 설정에 따라 접근 경로가 달라집니다.

가상 머신이나 컨테이너에서 호스트 프록시에 연결해야 한다면 호스트에 접근할 주소, 클라이언트의 수신 범위, 방화벽 규칙을 확인하세요. 필요한 로컬 네트워크에만 접근을 허용하고, 임시 점검을 위해 프록시 포트를 인터넷에 공개하지 마세요.

5단계: 프록시 진입점이 정상이라면 규칙, DNS, TUN 확인

연결 기록은 있지만 예상한 노드를 사용하지 않는 경우

먼저 클라이언트의 연결 세부 정보에서 테스트 도메인을 찾아 적용된 규칙과 정책 경로를 확인하세요. 규칙 모드에서 DIRECT는 코어가 규칙에 따라 직접 연결을 선택했다는 뜻입니다. 앱이 코어를 우회했다는 의미는 아닙니다. 정책 그룹에서 직접 연결이 선택되어 있거나 대상이 직접 연결 규칙에 해당하면 시스템 프록시를 켜도 결과는 달라지지 않습니다.

기존 설정을 기록한 뒤 잠시 전역 모드로 전환하고, 작동이 확인된 프록시 출구를 명시적으로 선택해 같은 URL을 다시 테스트할 수 있습니다. 전역 모드에서는 성공하지만 규칙 모드에서 실패한다면 규칙 순서, 도메인 일치 여부, 정책 그룹 선택을 확인한 뒤 원래 모드로 되돌리세요. 전역 모드 테스트 결과를 장기 설정 권장 사항으로 간주하지 마세요.

오류가 발생한 단계에 따라 원인 범위 좁히기

TUN 모드가 필요한 경우

TUN은 가상 네트워크 어댑터와 라우팅을 사용해 조건에 맞는 트래픽을 처리합니다. 프록시를 설정할 수 없거나 시스템 프록시를 읽지 않는 프로그램에 적합합니다. 잘못된 포트나 작동하지 않는 노드를 고치는 대안은 아닙니다. TUN을 켜도 모든 연결이 원격 노드를 사용하는 것은 아니며 최종 출구는 규칙에 따라 달라집니다.

curl에 환경 변수가 빠진 문제라면 변수를 바로잡는 편이 확인하기 쉽습니다. TUN이 꼭 필요할 때는 클라이언트 안내에 따라 서비스를 설치하거나 관리자 권한을 부여하고, 라우팅과 DNS를 확인하세요. 다른 VPN과의 충돌에도 유의해야 합니다. 시스템 프록시와 TUN을 비교할 때는 트래픽 처리 방식을 한 번에 하나씩만 바꿔 두 경로가 동시에 적용되어 원인을 가리는 일을 피하세요.

설정 복원 및 최종 확인

최종 확인에서는 브라우저, 프록시를 명시한 curl, 일반 curl 세 가지를 모두 테스트하고 같은 대상의 연결 기록을 살펴보세요. 브라우저는 성공하지만 일반 curl이 실패하면 터미널 설정을 계속 확인하세요. 프록시를 명시한 curl도 실패한다면 수신 포트와 코어 로그부터 다시 확인하세요. 클라이언트 토글의 색상이나 노드 지연 시간만으로 해결 여부를 판단하지 마세요.

1. 최종 포트, 프록시 진입점 유형, 적용된 설정 출처를 기록하세요. 예: “혼합 포트 7890, PowerShell 현재 세션 환경 변수”.
2. 문제 확인을 위해 잠시 꺼둔 필수 확장 프로그램을 하나씩 다시 켜고 테스트하세요. 문제가 재발하면 충돌 원인을 찾을 수 있습니다.
3. 점검 중 추가한 전역 모드, 광범위한 우회 항목, 중복 프록시 변수를 정리해 다음 실행에서 결과가 달라지지 않도록 하세요.

# macOS / Linux: 이번에 임시로 설정한 변수만 제거
unset http_proxy https_proxy all_proxy no_proxy

# Windows PowerShell: 이번 세션의 임시 항목 제거
Remove-Item Env:http_proxy, Env:https_proxy, Env:all_proxy, Env:no_proxy -ErrorAction SilentlyContinue

정리 명령으로 시작 파일이나 도구 설정에 저장된 영구 설정까지 되돌릴 수는 없습니다. 설정 파일에 추가했다면 해당 파일도 수정해야 합니다. 클라이언트를 종료한 뒤 시스템 프록시가 원래대로 돌아왔는지 확인하세요. 더는 수신하지 않는 로컬 포트를 시스템에서 계속 가리키는 상황을 방지할 수 있습니다.