1. 포트부터 확인하고 시스템 프록시와 VPN 방식 구분하기
클라이언트의 ‘설정’에서 ‘포트’, ‘인바운드’ 또는 ‘혼합 포트’를 찾아 실제 포트 번호를 확인한 다음, 코어가 실행 중인지 살펴보세요. 클라이언트마다 메뉴 이름이 다르므로 안내서에 나온 포트를 그대로 시스템에 입력하면 안 됩니다. 여기서는 127.0.0.1:7890을 예로 듭니다. 실제 HTTP 포트나 혼합 포트가 7890인 경우에만 그대로 사용하세요.
시스템 프록시는 앱이 참조할 프록시 주소를 지정하는 설정이지, 모든 네트워크 연결을 강제로 가로채는 스위치가 아닙니다. 브라우저는 대개 이 설정을 따르지만, 명령줄 도구마다 동작 방식이 다릅니다. 요약에서 ‘터미널은 환경 변수를 주로 사용한다’고 한 것은 흔히 확인하는 항목을 뜻합니다. 실제 요청을 보내는 것은 curl, Git, 패키지 관리자 같은 프로그램이며, 이들은 명령줄 옵션이나 자체 설정 파일도 참조할 수 있습니다.
| 경로 | 기능 | 흔한 오해 |
|---|---|---|
| 시스템 HTTP 프록시 | 시스템 설정을 따르는 앱에 프록시 주소 제공 | 스위치를 켜면 모든 앱이 프록시를 사용한다고 생각함 |
| HTTP / 혼합 포트 | 앱에서 보낸 프록시 요청을 수신합니다. 혼합 포트는 HTTP와 SOCKS를 모두 지원합니다. | SOCKS 전용 포트를 HTTP 프록시 항목에 입력함 |
| TUN 모드 | 가상 네트워크 인터페이스와 라우팅으로 조건에 맞는 트래픽을 처리합니다. | 켜기만 하면 라우팅, DNS, 분기 규칙을 확인할 필요가 없다고 생각함 |
| Android VPN 서비스 | Android의 VpnService를 통해 기기 트래픽을 수신합니다. | 데스크톱의 시스템 프록시 스위치와 같은 것으로 생각함 |
2. 프록시를 지정해 요청을 한 번 보내고 문제 발생 단계 확인하기
노드를 계속 바꾸기 전에 터미널에서 curl의 프록시 지정 옵션을 사용해 보세요. ‘앱이 시스템 프록시를 참조하는지’라는 변수를 건너뛰고 확인할 수 있습니다. 아래 주소는 테스트 대상일 뿐 속도 측정용 노드가 아닙니다. 요청이 클라이언트에 도달하는지, 어느 단계에서 실패하는지 확인하세요.
macOS 또는 Linux
curl -v --connect-timeout 10 --max-time 20 \
--noproxy "" \
--proxy http://127.0.0.1:7890 \
https://example.com/Windows PowerShell
curl.exe -v --connect-timeout 10 --max-time 20 --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/Windows에서는 curl.exe를 사용하세요. Windows PowerShell 5.1에서 curl은 다른 명령을 호출하는 별칭일 수 있습니다. 연결 시간 제한은 10초, 전체 제한은 20초로 설정했습니다. 테스트가 오래 대기하지 않도록 하는 값이지 노드 성능 기준은 아닙니다. --noproxy ""는 이번 요청의 우회 목록을 비우는 옵션입니다.
- 로컬 연결이 거부됨: 코어가 실행 중인지, 포트가 맞는지, 해당 포트가 다른 프록시 프로토콜만 지원하는지 먼저 확인하세요.
- HTTP 407 응답: 로컬 프록시에서 인증을 요구합니다. 실제 설정에 맞는 인증 정보를 제공하고, 비밀번호를 공개 로그에 붙여 넣지 마세요.
- CONNECT 성공 응답: HTTP 프록시가 터널 요청을 수락했다는 뜻입니다. 이후 TLS 핸드셰이크나 대상 서버 응답은 실패할 수 있습니다.
- 대상 사이트 응답 수신: 해당 요청에서 로컬 프록시 경로가 작동한다는 뜻입니다. 모든 노드, 도메인, 규칙이 정상이라고 단정할 수는 없습니다.
클라이언트의 ‘연결’ 또는 ‘로그’ 화면도 열어 요청 도메인, 적용된 규칙, 정책 그룹, 최종 아웃바운드를 확인하세요. 요청이 DIRECT로 표시된다면 트래픽이 이미 코어에 도달했지만 규칙에 따라 직접 연결되고 있을 수 있습니다. 이는 ‘시스템 프록시가 작동하지 않음’과는 다른 문제입니다.
3. 브라우저에서 연결되지 않을 때: 시스템 설정, 확장 프로그램, 개별 설정 확인
Chrome 및 Edge: 시스템 프록시를 확인한 뒤 프록시 확장 프로그램 사용 중지
- Windows 11에서 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’를 열고 ‘수동 프록시 설정’의 주소와 포트를 확인하세요. 클라이언트가 자동 구성 스크립트를 관리한다면 스크립트 출처도 확인해야 합니다.
- macOS에서 ‘시스템 설정’ → ‘네트워크’ → 현재 연결 → ‘세부사항’ → ‘프록시’로 이동하세요. 웹 프록시, 보안 웹 프록시 또는 자동 프록시 구성 설정이 클라이언트 설정과 일치하는지 확인합니다.
- Chrome의 ‘설정’ → ‘시스템’에서 컴퓨터의 프록시 설정을 여세요. Edge에서는 보통 ‘시스템 및 성능’에 있습니다. 위에 안내한 운영체제 설정 경로로 직접 이동해도 됩니다.
- 확장 프로그램 관리 페이지를 열고 프록시를 변경할 수 있는 확장 프로그램을 모두 잠시 사용 중지한 다음, 같은 테스트 주소에 다시 접속하세요. 기존 확장 프로그램 설정을 기록해 두고 테스트가 끝나면 필요에 따라 복원합니다.
프록시 확장 프로그램이 다른 포트를 지정하거나 PAC를 통해 특정 도메인을 직접 연결할 수 있습니다. PAC는 URL에 따라 프록시를 선택하는 자동 구성 스크립트입니다. 브라우저에 ‘조직에서 관리’라고 표시된다면 브라우저 정책을 확인하거나 관리자에게 문의하세요. 조직 설정을 덮어쓰려고 클라이언트 스위치를 반복해서 바꾸지 마세요.
Firefox: 프록시 설정 경로를 하나로 정하기
‘설정’ → ‘일반’ → ‘네트워크 설정’ → ‘설정’을 여세요. 운영체제 설정을 따르려면 ‘시스템 프록시 설정 사용’을 선택합니다. 별도로 테스트하려면 ‘수동 프록시 설정’을 선택하고 실제 HTTP 프록시 주소와 포트를 입력한 뒤 HTTPS에도 해당 프록시를 사용할지 확인하세요. ‘프록시 사용 안 함’을 선택한 채 시스템 프록시만 수정하지 마세요.
SOCKS v5를 사용한다면 프록시 항목과 포트가 SOCKS 또는 혼합 인바운드에 맞는지 확인하세요. 프록시 측에서 도메인을 확인해야 한다면 Firefox의 SOCKS v5 DNS 프록시 옵션도 확인합니다. 보안 DNS, 캐시, 프록시 유형에 따라 DNS 조회 경로가 달라질 수 있으므로 브라우저에서 보안 DNS가 켜져 있다는 이유만으로 Clash DNS가 반드시 작동하지 않는다고 단정하면 안 됩니다.
4. 터미널에서 프록시를 사용하지 않을 때: 실제 요청 프로그램에 환경 변수 설정
프록시를 지정한 테스트는 성공하지만 일반 터미널 요청이 실패한다면 프로그램이 프록시 설정을 읽는지 확인하세요. 환경 변수는 현재 프로세스와 그 이후에 실행되는 자식 프로세스에만 전달됩니다. 한 터미널 창에서 설정해도 이미 열려 있는 다른 창에는 자동으로 적용되지 않습니다. 먼저 현재 세션에서 테스트하고, 시작 파일에 바로 추가하지 마세요.
Bash 또는 Zsh: 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 -v --connect-timeout 10 --max-time 20 https://example.com/https_proxy 값에 http://를 사용하는 것은 잘못된 설정이 아닙니다. 로컬 프록시에 연결할 때 사용할 프로토콜을 나타내며, HTTPS 대상은 보통 HTTP CONNECT 터널로 연결합니다. 대상이 HTTPS라는 이유만으로 로컬 프록시 주소를 https://127.0.0.1:7890로 바꾸지 마세요.
HTTP 프록시를 사용할 때 curl은 소문자 http_proxy를 사용합니다. 다른 도구는 대소문자 변수를 다르게 처리할 수 있습니다. no_proxy는 프록시 우회 목록입니다. 테스트 도메인이 여기에 포함되면 프로그램이 직접 연결할 수 있습니다. 확인할 때 대소문자 변수 두 종류가 충돌하는지 살펴보고, 인증 정보가 포함된 변수를 공개하지 마세요.
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/모든 PowerShell 명령이나 앱이 curl과 같은 방식으로 변수를 읽는 것은 아닙니다. curl은 정상인데 다른 도구가 실패한다면 해당 도구의 프록시 설정 문서를 확인하세요. 그 결과만으로 시스템 전체 네트워크 설정을 바꾸면 안 됩니다. sudo를 사용하면 변수 설정이 제거될 수 있으므로 권한 상승 후 프로그램이 실제로 어떤 설정을 받는지 확인하세요.
SOCKS 및 앱별 설정
로컬에서 SOCKS 또는 혼합 인바운드를 실제로 열어 둔 경우, 아래와 같이 요청을 한 번 보내 DNS 조회 경로를 비교할 수 있습니다. socks5h는 도메인 조회를 프록시 측에 맡긴다는 뜻이고, 일반 socks5는 보통 로컬에서 먼저 조회합니다. 여기서도 7890은 실제 포트로 바꿔야 합니다.
curl -v --noproxy "" --proxy socks5h://127.0.0.1:7890 \
--connect-timeout 10 --max-time 20 https://example.com/일부 도구는 ALL_PROXY를 공용 프록시 변수로 사용할 수 있지만, 지원 여부와 우선순위는 시스템 전체에서 통일되어 있지 않습니다. Git에는 http.proxy 설정이 있을 수 있고 npm에도 별도의 프록시 설정이 있습니다. 환경 변수와 남아 있는 설정이 중복 적용되지 않도록 먼저 설정 출처를 확인하세요.
git config --show-origin --get-regexp '.*proxy.*'
npm config get proxy
npm config get https-proxy5. TUN 모드로 전환할 때
시스템 프록시를 읽지 않는 여러 앱의 트래픽을 처리해야 하거나 앱에 프록시 설정 항목이 없다면 TUN을 고려할 수 있습니다. TUN은 가상 네트워크 인터페이스이며 mihomo 같은 코어는 이를 통해 IP 트래픽을 수신할 수 있습니다. TUN은 트래픽을 받아들이는 경로를 제공할 뿐, 만료된 구독이나 잘못된 노드, 인증서 문제, 부적절한 분기 규칙을 자동으로 해결하지는 않습니다.
- 먼저 HTTP 또는 SOCKS 프록시를 지정한 요청으로 노드 경로가 작동하는지 확인한 다음, 클라이언트에서 ‘TUN 모드’ 또는 ‘가상 네트워크 어댑터’를 켜세요.
- 클라이언트 안내에 따라 시스템 서비스를 설치하거나 실행하고 필요한 권한을 부여하세요. Windows, macOS, Linux는 권한 처리 방식이 다르므로 다른 플랫폼의 절차를 그대로 적용하지 마세요.
- 기본 라우트가 충돌하지 않도록 다른 VPN이나 가상 네트워크 트래픽 처리 프로그램을 잠시 끄세요. 회사 장비에서는 먼저 관리 정책을 따르세요.
- 테스트 중에는 브라우저의 수동 프록시 설정과 터미널의 프록시 변수를 해제하세요. 명시적 프록시와 TUN이 동시에 개입하면 원인을 판단하기 어려워집니다.
- 요청을 다시 보내고 클라이언트의 연결 기록과 규칙 적용 결과를 확인하세요. 로컬 네트워크, 프린터, 사내 네트워크에 계속 접속할 수 있는지도 살펴봅니다.
Android에서는 보통 VPN 서비스를 통해 트래픽을 처리하므로 데스크톱의 가상 네트워크 드라이버 설치 절차를 그대로 적용하면 안 됩니다. 앱별 프록시에서 대상 앱이 제외되지 않았는지 확인하세요. 같은 Android 사용자 프로필이나 업무 프로필의 다른 VPN도 연결에 영향을 줄 수 있습니다.
6. 테스트 결과에 따라 정리하고 재현 가능한 설정만 유지하기
| 테스트 결과 | 우선 확인할 항목 | 다음 단계 |
|---|---|---|
| 프록시를 지정해도 로컬 포트에 연결할 수 없음 | 코어, 수신 주소, 포트, 인바운드 프로토콜 | 먼저 로컬 연결을 해결하고 구독 업데이트는 나중에 진행 |
| 프록시 지정 요청은 성공하지만 브라우저는 실패 | 시스템 프록시, 프록시 확장 프로그램, Firefox 개별 설정 | 프록시 설정 경로를 하나로 정한 뒤 다시 시도 |
| 브라우저는 되지만 터미널은 실패 | 환경 변수, 프로그램 설정, 컨테이너 네트워크 | 실제 요청을 보내는 프로그램에 개별 설정 |
| 요청이 코어에 도달했지만 DIRECT로 연결 | 규칙, 모드, 정책 그룹 | 대상 도메인에 적용된 규칙 확인 |
| TUN을 켠 뒤 일부 앱에서 계속 실패 | 라우팅, DNS, 앱 제외 설정, UDP 지원 | 해당 앱에서 실제 요청을 보내고 로그 확인 |
점검을 마치면 임시 변수를 정리하세요. 테스트 전에 프록시 설정이 있었다면 바로 삭제하지 말고 기존 값으로 복원해야 합니다. 아래 명령은 테스트 전에 해당 변수가 설정되어 있지 않았던 경우에 사용하세요. 영구 설정은 셸 시작 파일이나 시스템 환경 변수 화면에서 별도로 수정해야 합니다.
# Bash / Zsh: 현재 세션의 임시 프록시 설정 정리
unset http_proxy https_proxy all_proxy no_proxy
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY# PowerShell: 현재 세션의 임시 프록시 설정 정리
Remove-Item Env:http_proxy, Env:https_proxy, Env:all_proxy, Env:no_proxy -ErrorAction SilentlyContinue마지막으로 실제 인바운드 포트, 브라우저의 프록시 설정 경로, 터미널 프로그램의 프록시 설정, 요청에 적용된 아웃바운드 등 네 가지를 기록해 두세요. 네 항목이 명확하면 다음에 ‘시스템 프록시를 켰는데 작동하지 않음’ 문제가 생겨도 브라우저, 터미널, 노드 문제를 한데 섞지 않고 해당 단계부터 확인할 수 있습니다. 로그를 공유하기 전에는 구독 링크, 인증 정보, 개인 접속 기록을 가리세요.