권장 순서: 설치 파일 선택 → 코어 실행 → 구독 가져오기 및 활성화 → 노드 선택 → 시스템 프록시 켜기 → 요청 확인 → 로그인 시 자동 실행 설정. 처음 설정할 때는 규칙 모드와 시스템 프록시를 사용하고 TUN은 나중에 켜세요. 설치, 구독, 트래픽 처리 문제를 하나씩 분리해 확인할 수 있어 여러 설정을 한꺼번에 바꾼 뒤 원인을 찾기 어려워지는 일을 막을 수 있습니다.

1. 다운로드 전 Windows 아키텍처와 클라이언트 지원 여부 확인

Windows 11에서는 ‘설정’ → ‘시스템’ → ‘시스템 정보’에서 ‘시스템 종류’를 확인하세요. Windows 10에서는 ‘설정’ → ‘시스템’ → ‘정보’에서 확인할 수 있습니다. 일반적인 Intel 및 AMD PC에는 보통 x64 설치 파일을 사용합니다. ARM 기반 프로세서라면 클라이언트에서 제공하는 ARM64 파일을 우선 선택하세요. 브라우저의 비트 수나 설치 파일 용량으로 아키텍처를 판단하지 마세요.

  • x64 / amd64: 일반적으로 64비트 Intel 및 AMD Windows PC용입니다. 이름에 amd64가 들어가도 AMD 프로세서에서만 사용할 수 있다는 뜻은 아닙니다.
  • ARM64 / aarch64: 해당 아키텍처의 Windows on ARM 기기용입니다. 클라이언트와 코어가 해당 플랫폼을 지원하는지 확인해야 합니다.
  • x86 / ia32: 32비트 프로그램용입니다. 시스템이 32비트라면 x64만 제공하는 클라이언트를 설치할 수 없습니다.

클라이언트 다운로드 페이지에서 Windows 항목을 열고 지원하는 운영체제와 유지 관리 상태를 확인하세요. Clash for Windows는 더 이상 유지 관리되지 않으므로, 오래된 안내에 나온 화면을 현재 클라이언트의 기준으로 삼으면 안 됩니다. mihomo 기반 클라이언트를 사용한다면 클라이언트 버전과 코어 버전을 구분해 기록하세요. 문제를 보고할 때도 각각의 버전을 함께 남기면 좋습니다.

설치 파일은 보통 .exe 또는 .msi 형식이고, 포터블 버전은 대개 압축 파일로 제공됩니다. 포터블 버전은 먼저 고정된 폴더에 압축을 모두 푼 다음 실행하세요. 압축 파일 미리보기 창에서 바로 실행하면 안 됩니다. 다운로드 폴더 같은 임시 위치에 두었다가 파일을 정리하면 자동 실행 바로 가기가 작동하지 않을 수 있습니다.

2. 설치를 마친 뒤 코어가 정상적으로 실행되는지 확인

  1. 시스템 트레이의 백그라운드 프로세스를 포함해 실행 중인 이전 클라이언트를 모두 종료하세요. 처음 문제를 확인할 때는 프록시 클라이언트를 하나만 실행하는 것이 좋습니다.
  2. 설치 프로그램을 실행하고 안내에 따라 설치하세요. 포터블 버전은 압축을 푼 폴더에서 실행하면 됩니다. 보호된 폴더에 설치할 경우 설치 프로그램에서 관리자 권한을 요청할 수 있습니다.
  3. 클라이언트의 ‘설정’에서 실제 리스닝 포트, 코어 종류와 버전을 기록하고 ‘로그(Logs)’에서 시작 결과를 확인하세요.
  4. 설정 파싱 실패, 포트 바인딩 실패, 코어의 반복 종료가 없는지 확인한 뒤 구독을 가져오세요.

클라이언트마다 한국어 메뉴 이름이 다를 수 있습니다. 이 문서에서는 기능 위치를 표시하기 위해 ‘프로필(Profiles)’, ‘프록시(Proxies)’, ‘규칙(Rules)’, ‘로그(Logs)’라는 이름을 사용합니다. 특정 클라이언트의 버튼 이름을 모든 버전에 공통으로 적용되는 경로처럼 취급하지 않습니다. 창이 열려 있는지보다 코어가 실행 중인지가 더 중요합니다. 창이 정상적으로 표시되어도 코어가 실행되지 않았다면 시스템 프록시를 켜도 앱 요청이 서비스가 없는 로컬 포트로 전달됩니다.

설치가 막혀도 보안 기능부터 끄지 마세요

출처나 게시자에 대한 경고가 표시되면 다운로드 출처와 릴리스 정보를 확인하고 파일의 디지털 서명 상태도 살펴보세요. 출처를 확인할 수 없다면 설치를 중단하세요. 구성 요소가 없다는 메시지가 나오면 클라이언트 프로젝트의 안내에 따라 해당 런타임 구성 요소를 설치하세요. 출처가 불분명한 다운로드 사이트에서 DLL 파일을 받아 프로그램 폴더에 넣으면 안 됩니다.

창이 잠깐 나타났다가 사라진다면 먼저 클라이언트 로그를 확인하세요. 이어서 Windows ‘이벤트 뷰어’ → ‘Windows 로그’ → ‘응용 프로그램’과 ‘Windows 보안’ → ‘바이러스 및 위협 방지’ → ‘보호 기록’을 살펴보세요. 구체적인 오류 문구를 보관해 두면 반복해서 재설치하는 것보다 원인을 찾기 쉽습니다.

3. 구독을 가져오고 현재 사용 중인 설정을 확인

‘프로필(Profiles)’ 페이지에서 ‘가져오기’ 또는 ‘URL에서 가져오기’를 선택해 구독 주소를 붙여 넣으세요. YAML 파일이 있다면 로컬 파일 가져오기를 사용하면 됩니다. 구독 링크에는 인증 토큰이 포함되는 경우가 많으므로 비밀번호처럼 관리하세요. 공개된 문의 게시판이나 온라인 변환 사이트에 붙여 넣지 마세요.

  1. 가져온 뒤 한 번 업데이트해 성공 여부를 확인하세요. 설정 카드가 목록에 추가된 것만으로는 성공했다고 볼 수 없습니다.
  2. 가져온 프로필을 현재 설정으로 선택한 뒤 코어가 다시 불러올 때까지 기다리세요. 일부 클라이언트는 가져온 프로필을 자동으로 활성화하지 않습니다.
  3. ‘프록시(Proxies)’에서 예상한 정책 그룹과 노드가 표시되는지 확인하세요.
  4. ‘로그(Logs)’를 열어 지원되지 않는 필드, 존재하지 않는 참조 노드, 규칙 세트 로드 실패가 있는지 확인하세요.
증상먼저 확인할 항목다음 단계
HTTP 401 또는 403구독 토큰, 계정 상태, 접근 제한서비스 제공업체의 관리 페이지에서 링크를 새로 발급받으세요. 공개적으로 유출된 이전 링크를 다시 사용하지 마세요.
웹 페이지 또는 로그인 페이지가 열림관리 페이지 주소를 복사한 것은 아닌지 확인실제 클라이언트용 구독 링크를 사용하세요. HTML을 YAML 설정으로 가져오지 않도록 주의하세요.
파싱은 성공했지만 노드가 없음구독 형식, 계정 요금제, 노드 목록응답 내용이 현재 코어와 호환되는지 확인하세요. 다른 클라이언트에서만 지원되는 형식일 수 있습니다.
설정을 불러올 수 없음로그에 표시된 구체적인 필드와 줄 번호코어 지원 범위를 확인하고 원본 파일을 보관한 뒤 수정하세요.

구독 업데이트 중 네트워크 시간 초과가 발생하면 ‘구독 서버에 연결할 수 없는 문제’와 ‘노드를 사용할 수 없는 문제’를 구분해야 합니다. 일부 클라이언트에서는 구독을 다운로드할 때 직접 연결 또는 프록시 경로를 선택할 수 있습니다. 첫 연결이 아직 성립하지 않은 상태에서 사용할 수 없는 프록시 경로를 선택하면 업데이트가 계속 실패할 수 있습니다. 제공업체의 안내에 따라 가능한 연결 방식을 선택하고, 구독을 가져오기 위해 LAN 리스닝을 바로 허용하지 마세요.

4. 노드를 선택하고 시스템 프록시와 규칙 모드 켜기

먼저 ‘프록시(Proxies)’에서 규칙이 실제로 참조하는 정책 그룹을 찾아 노드를 선택하고 지연 시간을 테스트하세요. 그다음 ‘시스템 프록시’를 켜고 실행 모드를 ‘규칙(Rule)’로 설정합니다. 시스템 프록시는 트래픽이 들어오는 경로이고, 규칙 모드는 코어에 들어온 트래픽을 분기하는 방식입니다. 서로 다른 설정입니다.

  • Rule: 규칙 순서에 따라 프록시, 직접 연결 또는 차단을 결정합니다. 일반적인 사용에 적합합니다.
  • Global: 코어에 들어온 요청을 모두 전역 정책으로 처리합니다. 임시 비교에 사용할 수 있지만 시스템 프록시를 무시하는 프로그램까지 자동으로 처리하지는 않습니다.
  • Direct: 코어에 들어온 요청을 직접 연결로 처리합니다. 시스템 프록시가 켜져 있어도 직접 연결 경로로 나갈 수 있습니다.

지연 시간 테스트에서 120ms가 나와도 해당 시점에 해당 노드로 테스트 주소에 접속해 응답을 받았다는 뜻일 뿐입니다. 모든 웹사이트에 접속할 수 있다는 의미도, 다운로드 속도를 나타내는 것도 아닙니다. 테스트 주소에 접근할 수 없어 시간 초과가 발생할 수도 있습니다. 실제 접속하려는 주소로 요청을 보내고 연결 로그도 확인하세요.

Windows 설정에서 시스템 프록시 확인하기

‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’에서 수동 프록시 또는 설정 스크립트가 클라이언트의 현재 모드와 일치하는지 확인하세요. 수동 프록시 주소는 보통 127.0.0.1이며 포트는 클라이언트에 표시된 값을 사용합니다. PAC 모드에서는 스크립트가 프록시를 사용할 요청을 결정합니다. PAC 스크립트 주소를 로컬 HTTP 프록시 포트로 착각하지 마세요.

처음 문제를 확인할 때는 클라이언트의 일반 시스템 프록시 기능을 사용하고, 브라우저 프록시 설정을 제어하는 확장 프로그램은 잠시 꺼 두세요. Firefox 같은 앱은 별도의 프록시 설정을 사용할 수 있으며, 다른 브라우저도 확장 프로그램이나 조직 정책의 영향을 받을 수 있습니다. 시스템 설정에서 켜짐으로 표시된다고 해서 모든 앱이 이를 따르는 것은 아닙니다.

5. 요청을 직접 보내 확인하고 웹페이지 표시만으로 판단하지 않기

아래 예시에서는 로컬 HTTP 또는 mixed 포트 7890을 사용합니다. 진단용 명령일 뿐 모든 클라이언트의 기본 포트를 의미하지 않습니다. 실제 포트가 7897이라면 해당 값으로 바꾸세요. mixed 포트는 HTTP와 SOCKS 요청을 모두 받을 수 있지만, SOCKS 전용 포트를 HTTP 포트로 사용할 수는 없습니다.

# PowerShell에서 로컬 포트에 TCP 연결을 설정할 수 있는지 확인
Test-NetConnection 127.0.0.1 -Port 7890

# 로컬 HTTP 프록시를 지정해 요청하고 시스템 프록시 상속 문제를 배제
curl.exe --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://www.example.com/

Windows PowerShell에서는 curl이 별칭으로 동작해 매개변수 의미가 달라질 수 있으므로 curl.exe를 사용합니다. --noproxy ""는 이번 요청에서 프록시 우회 목록의 영향을 제거합니다. 명령에 적힌 대상 사이트는 연결 확인용 예시이므로 실제로 접속해야 하는 사이트로 바꿔 다시 테스트하세요.

  1. TcpTestSucceeded가 True이면 포트가 TCP 연결을 받아들인다는 뜻입니다. 이것만으로 원격 프록시가 정상 작동한다고 단정할 수는 없습니다.
  2. Connection refused가 표시되면 포트 입력이 잘못되지 않았는지, 코어가 종료되지는 않았는지 먼저 확인하세요.
  3. 프록시를 명시한 요청은 성공하지만 브라우저에서 실패한다면 브라우저 프록시 재정의, PAC, 캐시, 규칙 차이를 집중적으로 확인하세요.
  4. 요청이 연결 기록에 나타났지만 원격 연결이 시간 초과된다면 적용된 규칙, 실제 정책 그룹, 노드, DNS 오류를 확인하세요.

HTTP 프록시로 HTTPS에 접속할 때 출력에 200 Connection established가 표시되면 CONNECT 터널이 만들어졌다는 뜻일 뿐입니다. 이후 TLS 연결과 대상 사이트의 응답도 확인해야 합니다. 로컬 프록시를 명시해도 설정에 따라 해당 도메인이 DIRECT로 처리될 수 있으므로 ‘연결’ 또는 ‘로그’에서 전체 정책 경로를 확인하세요. 요청이 코어에 들어온 것만 보고 원격 노드를 사용했다고 단정하면 안 됩니다.

6. 포트 충돌, 방화벽, 관리자 권한을 각각 확인

포트 충돌: 프로세스를 먼저 확인하고 무작정 종료하지 않기

로그에 address already in use 또는 바인딩 실패가 표시되면 PowerShell에서 다음 명령을 실행하세요.

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

# 기존 명령으로도 리스닝 중인 프로세스의 번호를 확인할 수 있습니다
netstat -ano | findstr :7890

결과에 표시된 프로세스 번호를 ‘작업 관리자’ → ‘세부 정보’의 PID와 대조하세요. 다른 클라이언트나 이전 코어가 백그라운드에서 실행 중인 경우가 흔합니다. 해당 프로그램을 정상적으로 종료하는 것이 우선입니다. 포트를 변경해야 한다면 클라이언트 설정에서 수정하고 시스템 프록시를 다시 적용하세요. 브라우저 확장 프로그램과 터미널에 이전 포트가 고정되어 있다면 해당 값도 업데이트해야 합니다.

방화벽: 로컬 연결과 LAN 인바운드 연결 구분하기

127.0.0.1을 통해 이 PC에서만 프록시를 사용한다면 보통 ‘LAN 연결 허용’을 켤 필요가 없습니다. Windows 방화벽에서 네트워크 접근 알림이 표시되어도 공용 네트워크의 인바운드 연결을 허용해야 한다는 뜻은 아닙니다. 휴대전화 등 LAN 기기에서도 실제로 사용하려는 경우에만 리스닝 주소, 개인 네트워크 설정, 해당 인바운드 규칙을 확인하세요.

보안 소프트웨어가 코어의 아웃바운드 연결을 차단한다고 의심되면 차단 기록을 확인하고 프로그램의 전체 경로가 맞는지 살펴보세요. ‘Windows 보안’ → ‘방화벽 및 네트워크 보호’에서 관련 규칙을 확인할 수 있습니다. 꼭 필요한 범위만 허용하고, 방화벽 전체를 계속 꺼 두는 방식으로 문제를 해결하지 마세요. 조직 정책이 적용된 업무용 기기라면 관리자에게 확인을 요청하세요.

권한: 일반 시스템 프록시와 TUN은 다릅니다

현재 사용자의 시스템 프록시 설정에는 보통 항상 관리자 권한으로 실행할 필요가 없습니다. TUN은 가상 네트워크 어댑터, 라우팅, 관련 서비스를 사용하므로 권한 상승이 필요하거나 클라이언트가 미리 설치한 서비스가 처리해야 할 수 있습니다. 클라이언트에서 제공하는 서비스 설치 절차를 따르세요. 모든 문제에 ‘매번 관리자 권한으로 실행’을 적용하는 것은 올바른 해결책이 아닙니다.

7. 로그인 시 자동 실행을 설정하고 로그아웃 또는 재부팅 후 확인

데스크톱 클라이언트의 ‘시작 시 자동 실행’은 보통 사용자가 로그인한 뒤 앱을 실행한다는 뜻입니다. 로그인 전부터 프록시가 연결되는 것은 아닙니다. 먼저 클라이언트 ‘설정’에서 ‘시작 시 실행’ 또는 ‘로그인 시 실행’을 켜고, 필요하면 ‘시작 후 최소화’도 설정하세요. 시스템 프록시, TUN, 현재 프로필이 각각 복원되는지 따로 확인해야 합니다. 자동 실행만 설정하면 모든 상태가 자동으로 복원된다고 가정하지 마세요.

  1. ‘작업 관리자’ → ‘시작 앱’을 열어 클라이언트 항목이 사용으로 설정되어 있는지 확인하세요. Windows 10에서는 보통 이 페이지의 이름이 ‘시작프로그램’입니다.
  2. 클라이언트가 만든 시작 항목 하나만 사용하세요. 시작 폴더에 바로 가기를 추가하거나 작업을 별도로 예약해 중복 실행하지 마세요.
  3. 클라이언트를 정상 종료한 뒤 다시 열어 현재 구독, 규칙 모드, 정책 그룹 선택이 복원되는지 확인하세요.
  4. 로그아웃한 뒤 다시 로그인하거나 재부팅하세요. 네트워크 연결이 완료될 때까지 기다린 다음 시스템 트레이, 코어 로그, 시스템 프록시 포트, 실제 웹 요청을 확인하세요.

포터블 버전의 폴더를 옮기면 자동 실행 항목이 이전 경로를 가리킬 수 있습니다. 폴더를 고정된 위치로 되돌린 뒤 클라이언트에서 자동 실행을 껐다가 다시 켜세요. 관리자 권한으로 실행할 때만 정상 작동하지만 로그인 시 자동 실행에 실패한다면 서비스 설치 상태와 권한 설정을 먼저 확인하세요. 편의를 위해 Windows 사용자 계정 컨트롤을 끄지 마세요.

부팅 후 모든 노드가 시간 초과되더라도 Wi-Fi가 아직 연결되지 않았거나 시스템 시간이 동기화되지 않았거나, 네트워크가 사용 가능해지기 전에 규칙 세트 업데이트가 시작된 것이 원인일 수 있습니다. 네트워크가 안정될 때까지 기다렸다가 다시 테스트하고 로그의 시간 순서를 확인하세요. 데스크톱 화면이 나타났다고 해서 구독 서버와 노드에 바로 접속할 수 있는 것은 아닙니다.

8. 종료 후 인터넷 연결 문제와 최종 점검 목록

클라이언트를 종료하자마자 브라우저에서 인터넷이 안 된다면 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’에서 로컬 포트를 가리키는 수동 프록시나 PAC 스크립트가 남아 있는지 확인하세요. 클라이언트가 비정상 종료되면 설정을 복원하지 못했을 수 있습니다. 해당 클라이언트가 설정한 항목만 해제하고 조직에서 설정한 프록시는 직접 삭제하지 마세요.

터미널에서 계속 연결에 실패한다면 HTTP_PROXY, HTTPS_PROXY 또는 ALL_PROXY를 직접 설정한 적이 있는지 확인하세요. 이 환경 변수는 Windows 시스템 프록시 스위치와 별개입니다. 환경 변수를 영구적으로 수정한 뒤에는 보통 터미널을 새로 열어야 합니다. 브라우저가 다시 작동하더라도 터미널에 이전 주소가 남아 있는지 확인하세요.

  • 설치 확인: 클라이언트와 코어가 모두 실행되고 시작 오류가 계속 로그에 나타나지 않습니다.
  • 설정 확인: 구독 업데이트에 성공했고 대상 프로필이 활성화되어 있으며 정책 그룹에서 참조하는 노드가 존재합니다.
  • 프록시 확인: 지정한 포트 테스트와 실제 앱 요청이 모두 완료되고 적용된 규칙과 정책 경로도 확인했습니다.
  • 자동 실행 확인: 다시 로그인한 뒤 클라이언트 인스턴스가 하나만 실행되고 포트, 프로필, 프록시 상태가 예상대로입니다.
  • 종료 확인: 정상 종료 후 직접 연결해야 하는 네트워크를 계속 사용할 수 있고 작동하지 않는 로컬 프록시 설정이 남아 있지 않습니다.

추가로 문제를 확인해야 한다면 Windows 버전, CPU 아키텍처, 클라이언트와 코어 버전, 리스닝 포트, TUN 사용 여부, 실패한 요청 하나에 해당하는 로그를 정리하세요. 화면을 캡처하기 전에는 구독 주소, 토큰, 노드 비밀번호, 관리 인터페이스 키를 가리세요. 이 정보를 바탕으로 문제를 재현하는 편이 반복해서 설치하는 것보다 효과적입니다.