Clash 시스템 프록시를 켰는데도 연결되지 않을 때: 브라우저와 터미널별 점검 방법

먼저 요청이 커널에 도달하지 못한 것인지, 규칙에 따라 직접 연결된 것인지 구분하세요

먼저 클라이언트의 연결 화면을 열고 대상 웹사이트에 접속해 보세요. 시스템 프록시는 운영체제가 제공하는 프록시 설정이며, 이 설정을 읽는 앱에서만 적용됩니다. 클라이언트 버튼에 ‘켜짐’이라고 표시되어도 브라우저, 터미널, 백그라운드 서비스가 모두 프록시에 연결됐다는 뜻은 아닙니다.

먼저 두 구성 요소의 역할을 알아두세요. GUI 클라이언트는 시스템 설정을 전환하고 연결 상태를 표시하며, Clash 또는 mihomo 커널은 포트를 열고 규칙을 적용해 요청을 전달합니다. mihomo는 이름이 바뀐 Clash Meta 커널입니다. 커널이 정상적으로 실행되고, 시스템 프록시가 올바르게 설정되며, 앱이 해당 설정을 읽어야 요청이 커널로 전달됩니다.

대상 페이지를 닫았다가 다시 열거나 새 명령줄 요청을 실행하세요. 브라우저 캐시, 백그라운드 장기 연결, 연결 화면의 필터가 확인을 방해할 수 있습니다. 새 기록이 없다는 사실만으로 결론을 내릴 수는 없습니다. TUN 모드를 사용 중이라면 먼저 현재 상태를 기록하세요. TUN은 가상 네트워크 어댑터로 트래픽을 가로채므로 테스트 결과가 시스템 프록시 적용 여부만을 반영하지 않을 수 있습니다.

로컬 포트 확인: 7890은 예시입니다

먼저 클라이언트에 표시된 HTTP 포트 또는 혼합 포트를 확인한 뒤 시스템 설정을 점검하세요. 혼합 포트는 하나의 포트에서 HTTP와 SOCKS 프록시 연결을 모두 받을 수 있습니다. 여기서는 127.0.0.1:7890을 예시로 사용합니다. 실제 포트가 7897이라면 아래 명령에서도 포트 번호를 바꾸세요.

# mihomo 설정 예시이며 전체 구독 설정이 아닙니다
mixed-port: 7890
allow-lan: false
mode: rule

관리 인터페이스 포트를 프록시 포트로 착각하지 마세요. external-controller는 제어 인터페이스입니다. 응답이 오더라도 HTTP 프록시 리스너를 대신할 수 없습니다. 로컬 브라우저 연결을 위해 ‘LAN 허용’을 켤 필요도 없습니다. 같은 시스템에서는 보통 루프백 주소를 사용하면 됩니다.

포트가 실제로 연결 대기 중인지 확인

Windows PowerShell에서 다음 명령을 실행하세요. 포트가 연결 대기 중이라고 표시되더라도 해당 프로세스가 현재 클라이언트의 커널인지 확인해야 합니다.

Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

# 앞 명령의 출력에 나온 프로세스 ID를 입력하라는 메시지에 입력합니다
Get-Process -Id (Read-Host "OwningProcess 프로세스 ID 입력")

macOS에서는 lsof, Linux에서는 ss를 사용하세요. 출력이 없다면 먼저 커널 시작 로그, 실제 포트 번호, 시작 실패 여부를 확인하세요. 브라우저 설정부터 바꾸지는 마세요.

# macOS
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux
ss -lntp 'sport = :7890'

브라우저 점검: 시스템 설정부터 확인하고 확장 프로그램의 간섭을 배제하세요

1단계: 시스템 프록시가 설정됐는지 확인

Windows 11에서 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’ → ‘수동 프록시 설정’ → ‘편집’을 여세요. 수동 프록시 모드에서는 주소가 로컬 루프백 주소를 가리키고 포트가 클라이언트 설정과 일치해야 합니다. 클라이언트가 PAC(프록시 자동 구성 스크립트)를 사용한다면 수동 프록시를 켜는 대신 ‘설정 스크립트 사용’과 스크립트 주소를 확인하세요.

macOS 13 이상에서는 ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 서비스 → ‘세부사항’ → ‘프록시’를 여세요. 웹 프록시(HTTP)와 보안 웹 프록시(HTTPS)를 확인합니다. ‘보안 웹 프록시’라는 이름만 보고 로컬 포트에 TLS가 필요하다고 생각하지 마세요. 보통 로컬 HTTP 프록시 포트에 연결한 뒤 프록시가 HTTPS 터널을 설정합니다.

• 시스템 프록시를 자동으로 수정하는 다른 클라이언트를 종료해, 설정이 적용되자마자 덮어써지지 않도록 하세요.
• 프록시 예외 목록을 확인하세요. 대상 도메인이 우회 목록에 있으면 브라우저가 직접 연결할 수 있습니다.
• Wi-Fi, 유선 네트워크 또는 VPN을 전환한 뒤 설정을 다시 확인하세요. 특히 macOS에서는 현재 네트워크 서비스가 바뀌었는지 확인해야 합니다.
• 조직에서 관리하는 기기라면 먼저 정책 제한을 확인하세요. 관리 정책이 강제로 덮어쓰는 항목을 반복해서 수정하지 마세요.

2단계: 브라우저 자체의 프록시 설정 확인

Chrome 또는 Edge의 확장 프로그램 관리 페이지에서 프록시 제어 권한이 있는 확장 프로그램을 잠시 사용 중지한 뒤 새 일반 창에서 테스트하세요. 브라우저 프록시 확장 프로그램은 시스템 설정을 덮어쓸 수 있습니다. 시크릿 창만으로 비교하면 안 됩니다. 확장 프로그램이 시크릿 모드에서 실행되도록 허용될 수 있고 브라우저 정책도 계속 적용되기 때문입니다.

Firefox에서 ‘설정’ → ‘일반’ → 페이지 아래쪽의 ‘네트워크 설정’ → ‘설정’을 여세요. 클라이언트 설정을 따르려면 ‘시스템 프록시 설정 사용’을 선택하세요. 별도로 테스트하려면 잠시 수동 프록시를 선택하고 실제 주소를 입력할 수 있습니다. 테스트가 끝나면 원래 설정으로 되돌리세요. 그래야 나중에 클라이언트를 바꿀 때 이전 포트가 남지 않습니다.

특정 브라우저에서만 문제가 발생하면 다른 브라우저로 같은 주소에 접속해 비교하세요. 다른 브라우저에서 연결 화면에 기록이 남는다면 문제가 발생한 브라우저의 확장 프로그램, 프로필, 기업 정책부터 확인하세요. 커널을 먼저 다시 설치할 필요는 없습니다.

터미널 점검: 프록시를 직접 지정해 비교 테스트

먼저 환경 변수에 의존하지 말고 curl에 프록시를 직접 지정하세요. 많은 명령줄 도구는 데스크톱 시스템 프록시를 자동으로 읽지 않습니다. 브라우저가 연결된다고 해서 터미널도 연결되어야 하는 것은 아닙니다. 아래 명령은 macOS와 Linux의 일반적인 셸에서 사용할 수 있으며, 테스트 주소는 https://example.com/입니다.

curl -q -v --connect-timeout 10 --max-time 30 \
  --noproxy "" \
  --proxy http://127.0.0.1:7890 \
  https://example.com/ -o /dev/null

Windows PowerShell에서는 curl.exe를 명시적으로 호출하세요. Windows PowerShell 5.1에서 curl 별칭이 다른 명령을 가리키는 문제를 피할 수 있습니다. 응답 본문을 버리려면 NUL을 사용하세요.

curl.exe -q -v --connect-timeout 10 --max-time 30 --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/ -o NUL

• -q는 첫 번째 인수로 지정해야 사용자 수준 curl 설정 파일이 테스트에 영향을 주지 않습니다.
• --noproxy ""는 이번 요청의 우회 목록을 비워 대상 주소가 프록시 예외로 제외되는 일을 방지합니다.
• --connect-timeout 10은 연결 단계의 대기 시간을 제한하고 --max-time 30은 전체 전송 시간을 제한합니다. 단위는 모두 초입니다.
• 상세 출력에서 먼저 127.0.0.1의 실제 포트에 연결됐는지 확인한 다음 HTTPS CONNECT 터널과 후속 응답을 확인하세요.

Connection refused가 표시되면 로컬 리스너 주소와 포트를 다시 확인하세요. 407 Proxy Authentication Required가 표시되면 로컬 프록시에서 인증이 활성화되어 있는지 확인하세요. 터널이 설정된 뒤 시간 초과가 발생한다면 정책 그룹과 노드를 점검하세요. 웹사이트에서 403을 반환해도 프록시를 사용하지 않은 것은 아닙니다. 대상 사이트의 접근 제한일 수 있습니다.

웹페이지가 열리는지만으로 결론을 내리지 마세요. 프록시를 직접 지정한 명령이 성공하고 클라이언트 연결 화면에 해당 대상이 표시되어야 앱에서 커널까지 연결된 것으로 볼 수 있습니다. 그다음 규칙이 예상한 출구를 선택했는지 확인하세요.

터미널 환경 변수 설정: HTTP 프록시와 SOCKS 프록시 구분

macOS 및 Linux: 현재 셸에서만 적용

현재 터미널에서 먼저 아래 설정을 실행한 뒤 --proxy 없이 명령을 실행해 확인하세요. https_proxy는 HTTPS 대상에 접속할 때 사용할 프록시를 지정합니다. 변수 값으로 http://를 사용해도 됩니다. 여기서는 로컬 프록시 서비스의 프로토콜을 나타내기 때문입니다.

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 -q -v --connect-timeout 10 --max-time 30 \
  https://example.com/ -o /dev/null

정상적으로 작동하는 것을 확인한 뒤 ~/.zshrc 또는 ~/.bashrc처럼 현재 셸이 실제로 읽는 파일에 설정을 추가하세요. 처음부터 전역 설정에 넣으면 클라이언트를 종료한 뒤에도 터미널이 닫힌 포트에 연결을 시도할 수 있습니다. 환경 변수는 보통 현재 프로세스와 이후에 실행되는 하위 프로세스에만 영향을 주며, 이미 실행 중인 프로그램을 자동으로 바꾸지는 않습니다.

도구가 SOCKS를 지원한다면 아래처럼 한 번만 호출해 테스트할 수 있습니다. socks5h의 h는 프록시가 대상 도메인의 DNS 조회를 처리한다는 뜻입니다. socks5는 보통 로컬에서 대상 도메인을 먼저 조회합니다. 실제로 SOCKS 또는 혼합 리스너가 활성화된 포트에서만 사용할 수 있습니다.

curl -q --proxy socks5h://127.0.0.1:7890 \
  --noproxy "" --connect-timeout 10 --max-time 30 \
  https://example.com/ -o /dev/null

Windows PowerShell: 현재 프로세스의 환경 변수 설정

PowerShell에서는 $env:를 사용하세요. 셸의 export 명령을 그대로 사용하면 안 됩니다. 아래 설정은 현재 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 -q -v --connect-timeout 10 --max-time 30 https://example.com/ -o NUL

첫 번째 테스트에서 setx를 사용하지 마세요. 환경 변수 값이 영구 저장되고 보통 새 프로세스를 실행해야 변경 사항이 적용되므로 현재 창의 이전 값과 혼동할 수 있습니다. 도구마다 지원하는 변수 이름과 우선순위가 다릅니다. curl의 HTTP 프록시 변수에는 소문자 http_proxy를 사용하세요. 모든 도구가 대문자 HTTP_PROXY를 동일하게 읽는다고 가정하면 안 됩니다.

이전 환경 변수와 도구 자체의 프록시 설정 확인

프록시를 직접 지정하면 성공하지만 일반 명령은 실패한다면 ALL_PROXY, all_proxy, NO_PROXY, no_proxy가 이전 포트를 가리키거나 대상 도메인을 포함하는지 확인하세요. Git 등의 도구에는 별도 설정이 있을 수 있습니다. 아래 명령은 설정 출처를 확인만 하며 파일을 수정하지 않습니다.

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

출력이 없어도 오류라는 뜻은 아닙니다. 일치하는 항목을 찾지 못했다는 의미일 수 있습니다. 이전 설정을 발견하면 어느 파일에 있는지, 다른 작업 환경에서 계속 사용하는지 확인한 뒤 수정 여부를 결정하세요. 터미널 출력을 공유하기 전에는 프록시 계정, 비밀번호, 구독 링크, 액세스 토큰이 포함된 주소를 가리세요.

커널에 도달했는데도 프록시를 사용하지 않을 때: 규칙과 정책 그룹 확인

먼저 연결 세부 정보에서 적용된 규칙과 최종 출구를 확인하세요. 규칙 모드는 설정 순서에 따라 일치하는 항목을 찾습니다. DIRECT에 일치했다면 커널이 직접 연결을 선택한 것이지 시스템 프록시가 작동하지 않는 것이 아닙니다. 정책 그룹에 DIRECT가 포함될 수도 있으므로 그룹 이름만 보지 말고 전체 경로를 확인하세요.

1. 같은 대상 주소로 테스트하고 현재 모드, 적용된 규칙, 정책 경로를 기록하세요.
2. 선택한 프록시 그룹에서 직접 연결 옵션이 아니라 실제로 사용 가능한 노드를 선택했는지 확인하세요.
3. 필요하다면 잠시 전역 모드로 전환하고 전역 정책 그룹에서 프록시 노드를 선택했는지 확인한 뒤 같은 요청을 보내세요.
4. 전역 모드에서는 연결되지만 규칙 모드에서는 직접 연결된다면 규칙 순서를 확인하세요. 두 모드 모두 시간 초과가 발생한다면 노드와 로그를 확인하세요.
5. 테스트가 끝나면 규칙 모드로 되돌려 다른 앱의 트래픽 분배 방식이 계속 바뀌지 않도록 하세요.

‘프록시를 사용함’과 ‘대상에 접속할 수 있음’은 서로 다른 문제입니다. 노드 장애, 원격 제한, DNS 조회 실패는 요청이 커널에 도달한 뒤에도 발생할 수 있습니다. 로컬 포트 연결 거부를 해결하려고 도메인 규칙을 계속 추가하지 마세요. 적용된 규칙을 확인하지 않은 채 클라이언트를 다시 설치하는 것도 해결책이 아닙니다.

WSL, 컨테이너, TUN: 특수한 실행 환경은 마지막에 점검

먼저 명령이 실제로 어느 시스템에서 실행되는지 확인하세요. WSL, Docker 컨테이너, 가상 머신 안의 127.0.0.1이 호스트를 가리키는 것은 아닙니다. WSL 2는 NAT 네트워크와 미러링 네트워크의 동작이 다르고, Docker에서 호스트 주소는 실행 환경에 따라 달라집니다. 호스트 브라우저는 작동하지만 컨테이너에서는 연결이 거부된다면 루프백 주소를 그대로 사용하지 말고 먼저 네트워크 경계를 확인하세요.

경계를 넘어 연결해야 하는 경우에만 리스너 주소, LAN 허용, 방화벽 규칙을 검토하세요. 프록시 리스너를 다른 네트워크 인터페이스에 개방하면 접근 범위가 넓어지므로 신뢰할 수 있는 출처로 제한하고 필요한 경우 인증을 설정해야 합니다. 터미널 문제를 점검한다는 이유로 포트를 공용 네트워크에 노출하지 마세요.

프록시 설정을 지원하지 않고 프록시 환경 변수도 읽지 않는 앱이라면 TUN 모드를 고려하세요. TUN은 보통 시스템 권한이 필요하며 라우팅과 DNS를 가로챕니다. 잘못된 포트를 바로잡는 간편한 방법이 아닙니다. 켜기 전에 기존 상태를 기록하세요. 다른 VPN이나 가상 네트워크 어댑터가 동시에 트래픽을 가로채면 문제를 찾기 어려워질 수 있습니다.

설정 복원 후 최소한의 점검 기록을 남기세요

먼저 임시로 변경한 설정을 복원한 뒤 평소 작업 흐름이 정상인지 확인하세요. 이전에 프록시 변수를 설정하지 않았다면 아래 명령으로 이번에 추가한 변수만 지울 수 있습니다. 기존 값이 있었다면 삭제하지 말고 원래 값으로 복원하세요.

# macOS / Linux: 이 문서에서 임시로 설정한 소문자 변수만 삭제
unset http_proxy https_proxy no_proxy

# PowerShell: 이 문서에서 임시로 설정한 프로세스 변수만 삭제
Remove-Item Env:http_proxy, Env:https_proxy, Env:no_proxy -ErrorAction SilentlyContinue

마지막으로 실제 리스너 포트, 프록시를 직접 지정한 curl 테스트 결과, 브라우저가 사용하는 프록시 출처, 연결 세부 정보의 규칙과 출구 등 네 가지를 기록하세요. 이 정보가 있으면 ‘프록시를 켰는데도 안 된다’는 설명에 그치지 않고 앱 설정, 로컬 리스너, 커널 전달 중 어디에서 문제가 발생했는지 좁힐 수 있습니다.