1. 클라이언트, 코어, 구독은 각각 어떤 역할을 하나요?

클라이언트는 조작 화면을 제공하고, 코어는 연결과 규칙을 처리하며, 구독은 설정 데이터를 제공합니다. 클라이언트를 설치했다고 바로 사용할 수 있는 노드가 생기는 것은 아닙니다. 시작하기 전에 클라이언트가 코어를 실행할 수 있는지, 코어가 설정을 해석할 수 있는지, 설정에 포함된 노드 서버가 여전히 유효한지 확인하세요.

클라이언트를 고를 때는 먼저 운영체제와 프로세서 아키텍처를 확인한 뒤, 사용 중인 코어가 구독에 포함된 프로토콜과 설정 항목을 지원하는지 살펴보세요. 설정에 “알 수 없는 프록시 유형”이 표시될 때 포트를 계속 바꿔도 대개 해결되지 않습니다. 먼저 프로토콜 지원 여부를 확인하세요. 플랫폼별 클라이언트는 클라이언트 다운로드 페이지에서 확인하고, 제품별 차이는 클라이언트 선택 가이드를 참고하세요.

2. 구독 링크를 제대로 가져왔는지 어떻게 확인하나요?

가져오기, 적용, 확인은 각각 별개의 단계입니다. 목록에 설정 이름이 표시되는 것은 클라이언트가 항목을 저장했다는 뜻일 뿐입니다. 내려받은 내용이 유효한지 확인하고 해당 설정을 현재 설정으로 선택해야 합니다.

  1. 서비스 제공업체에서 Clash 또는 mihomo용 구독 링크를 복사하세요. 계정 관리 페이지 주소를 구독 링크로 착각하지 않도록 주의하세요.
  2. 클라이언트의 “설정” 또는 “Profiles” 페이지에서 URL 가져오기 메뉴를 찾으세요. 메뉴 위치는 클라이언트마다 다르므로 현재 화면을 기준으로 확인하세요.
  3. 가져온 뒤 업데이트 시간과 오류 메시지를 확인하고, 해당 설정을 선택한 다음 코어에서 파싱 오류가 없는지 살펴보세요.
  4. 프록시 정책 페이지에서 노드를 하나 선택한 다음 시스템 프록시를 켜고 브라우저에서 실제 요청을 보내 보세요.

일부 링크는 노드 목록만 반환하므로 호환되는 proxy-providers 설정에 넣어야 하며, 완전한 Profile처럼 바로 가져올 수 없습니다. 형식을 변환하려고 비공개 구독을 신뢰할 수 없는 온라인 서비스에 제출하지 마세요. 서비스 제공업체가 안내하는 호환 형식을 우선 사용하세요.

3. Profile은 노드 목록인가요? 로컬 수정 사항이 유지되나요?

Profile은 전환해 사용할 수 있는 설정 묶음이며, 노드만 포함하는 것은 아닙니다. 전체 설정에는 수신 포트, DNS, 정책 그룹, 분기 규칙도 포함될 수 있습니다. 원격 Profile을 업데이트하면 내려받은 파일을 직접 수정한 내용이 덮어써질 수 있습니다. 개인 설정을 보존하려면 클라이언트의 영구 오버라이드, 병합 또는 덮어쓰기 기능을 사용하세요.

아래는 설정 조각이며, 단독으로 가져올 수 있는 완전한 구독이 아닙니다. 포트, 모드, 로그는 서로 독립된 설정 항목임을 보여주는 예입니다. 기존 설정을 수정하고 파일 끝에 같은 키를 중복해서 추가하지 마세요.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

“일상용 구독”, “임시 테스트”처럼 용도에 맞게 설정 이름을 지정하세요. 전환한 뒤에는 현재 설정 이름과 정책 그룹에서 선택된 항목을 확인하세요. 로컬 설정을 복사하기 전에는 노드 비밀번호가 포함되어 있는지도 확인하고, 백업 파일도 안전하게 보관하세요.

4. 규칙, 전역, 직접 연결 모드 중 무엇을 선택해야 하나요?

일상적인 사용에는 규칙 모드, 분기 문제를 잠시 분리해 확인할 때는 전역 모드, 프록시를 거치지 않아야 할 때는 직접 연결 모드를 사용하세요. 모드는 연결의 출구를 선택하는 방식을 바꿀 뿐, 잘못된 비밀번호나 만료된 노드, 접속할 수 없는 프록시 서버를 해결해 주지는 않습니다.

모드주요 동작확인할 항목
rule규칙 순서에 따라 연결 출구 정책을 매칭일치한 규칙과 정책 그룹에서 현재 선택된 항목
global일반 연결에 전역 정책 적용현재 GLOBAL에서 선택한 출구
direct일반 연결은 직접 연결로 전송로컬 네트워크에서 대상에 직접 접속할 수 있는지

아래 규칙 조각은 매칭 순서를 보여주는 예시입니다. 기존 proxy-groups에 “프록시 선택”이라는 정책 그룹이 정의되어 있다고 가정합니다. example.com은 규칙 문법을 보여주기 위한 예시 도메인이며, 접속 가능 여부를 확인하는 대상은 아닙니다.

mode: rule
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,프록시 선택

규칙은 보통 위에서 아래 순서로 매칭되며, 마지막의 MATCH가 앞선 규칙에 일치하지 않은 연결을 처리합니다. 기본 규칙을 앞에 두면 뒤에 있는 규칙은 적용되지 않습니다. “규칙 모드”를 “모든 연결이 프록시를 통과하는 모드”라고 생각하는 것도 흔한 오해입니다. 규칙에서 DIRECT를 선택할 수 있고, 정책 그룹 자체가 직접 연결을 선택했을 수도 있습니다.

5. 시스템 프록시를 켰는데 터미널에서는 왜 프록시를 사용하지 않나요?

시스템 프록시는 모든 네트워크 연결을 강제로 가로채는 스위치가 아닙니다. 시스템 설정을 따르는 앱에 프록시 주소를 전달하는 기능입니다. 일부 명령줄 도구, 게임, 자체 네트워크 스택을 사용하는 앱은 이 설정을 자동으로 사용하지 않습니다. 브라우저도 프록시 확장 프로그램이나 별도 설정의 영향을 받을 수 있습니다.

명시적 프록시를 사용해 코어 문제와 앱 설정 문제를 구분하세요

실제 혼합 포트가 7890이라고 가정하면 Windows PowerShell에서 기본 제공되는 curl.exe로 요청을 보낼 수 있습니다. 프로그램 이름을 명시하면 일부 환경에서 curl이 다른 명령으로 해석되는 일을 피할 수 있습니다.

curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 https://example.com/

이 명령은 지정한 포트의 프록시 요청 경로를 확인합니다. 예시 사이트에 접속하므로 출구 지역이나 모든 웹사이트의 접속 가능 여부까지 증명하지는 않습니다. 명시적 프록시 요청은 성공하지만 도구를 직접 실행하면 실패하는 경우, 구독을 바로 바꾸기보다 해당 도구의 프록시 설정을 확인하세요.

필요할 때 현재 터미널에만 환경 변수를 설정하기

$env:http_proxy = "http://127.0.0.1:7890"
$env:https_proxy = "http://127.0.0.1:7890"

이 PowerShell 설정은 현재 프로세스와 이후 시작한 하위 프로세스에만 적용되며, 해당 도구가 관련 변수를 지원해야 합니다. https_proxy 값에 http://를 사용하는 것은 로컬 HTTP 프록시 프로토콜을 지정한다는 뜻이지, 대상 HTTPS 사이트가 암호화되지 않는다는 뜻은 아닙니다. 변수를 지우려면 Remove-Item Env:http_proxy, Env:https_proxy -ErrorAction SilentlyContinue를 실행하세요.

6. 7890 포트를 사용 중이라고 나옵니다. 어디를 바꿔야 하나요?

먼저 포트를 점유한 프로세스를 확인한 다음, 중복 프로세스를 종료할지 수신 포트를 바꿀지 결정하세요. 로그의 address already in use는 보통 코어가 지정된 주소와 포트를 열지 못했다는 뜻이며, 원격 노드의 응답 시간 초과를 의미하지는 않습니다.

Windows에서는 로컬 수신 포트와 해당 프로세스 ID를 조회할 수 있습니다.

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

OwningProcess에 표시된 숫자를 확인한 뒤 작업 관리자의 “세부 정보”에서 PID를 대조하거나, Get-Process -Id 뒤에 해당 숫자를 입력해 조회하세요. 포트 번호만 보고 정체를 알 수 없는 프로세스를 종료하지 마세요. 다른 프록시 클라이언트나 같은 클라이언트의 이전 코어 프로세스가 포트를 점유하는 경우가 많습니다.

  1. 클라이언트가 중복 실행된 경우 필요하지 않은 쪽을 정상적으로 종료한 다음 현재 코어를 다시 시작하세요.
  2. 포트를 바꿔야 한다면 실제 적용 중인 mixed-port 값을 7890에서 사용 가능한 7891로 변경할 수 있습니다.
  3. 앱이 이전 포트로 계속 접속하지 않도록 시스템 프록시, 터미널 환경 변수, 앱의 수동 프록시 주소도 함께 수정하세요.

클라이언트가 화면 설정으로 YAML의 포트를 덮어쓸 수 있으므로, 변경한 뒤 실행 로그나 수신 포트 목록에서 최종 값을 확인하세요. 프록시 수신 포트와 컨트롤 인터페이스 포트는 다릅니다. external-controller는 관리 인터페이스용이므로 브라우저의 프록시 포트 입력란에 넣지 마세요.

7. 노드 연결이 시간 초과됩니다. 구독이 만료된 건가요?

반드시 그런 것은 아닙니다. 시간 초과는 정해진 시간 안에 특정 테스트가 끝나지 않았다는 뜻일 뿐입니다. 테스트 URL, DNS, 로컬 네트워크, 노드 프로토콜, 서버 상태가 모두 결과에 영향을 줍니다. 클라이언트의 지연 시간 테스트는 대역폭 테스트가 아니며, 지연 시간이 낮다고 다운로드 속도가 더 빠른 것도 아닙니다.

문제를 확인할 때는 “발생 시각, 대상 도메인, 오류 유형, 선택된 정책” 네 가지 정보만 기록해도 충분합니다. connection refused는 보통 연결이 거부됐다는 뜻이고, i/o timeout은 관련 읽기·쓰기 작업이 시간 초과됐다는 뜻입니다. 어느 쪽도 로그 한 줄만으로 계정 만료를 판단할 수는 없습니다.

8. DNS와 TUN 모드를 처음부터 켜야 하나요?

먼저 일반 프록시 연결을 확인한 뒤 앱 요구에 따라 TUN을 추가하고, DNS는 트래픽 처리 방식과 함께 점검하세요. TUN은 가상 네트워크 인터페이스로 트래픽을 가져오므로 시스템 프록시를 따르지 않는 앱에 유용합니다. 다만 실제 적용 범위는 운영체제, 라우팅, 제외 설정에 따라 달라지며, 켰다고 모든 트래픽이 프록시 노드를 통해 나가는 것은 아닙니다.

DNS 문제는 증상부터 확인하세요

로그에 도메인 확인 실패가 표시되면 “노드 서버 도메인을 확인하지 못한 경우”와 “대상 웹사이트 도메인을 확인하지 못한 경우”를 구분하세요. 전자는 프록시 연결 자체를 막을 수 있고, 후자는 대상 요청의 DNS 조회 경로와 관련이 있습니다. 기존 구독을 통째로 덮어쓰도록 DNS 설정 전체를 복사하지 마세요. DNS 서버, 조회 방식, 트래픽 분기까지 한꺼번에 바뀔 수 있습니다.

TUN을 켜기 전에 확인할 세 가지

  1. 코어와 클라이언트가 현재 운영체제의 TUN 기능을 지원하고 필요한 권한을 갖췄는지 확인하세요. 일부 데스크톱 클라이언트는 서비스 모드나 관리자 권한이 필요합니다.
  2. 일반적인 명시적 프록시 요청이 성공하는지 확인하세요. 작동하지 않는 노드 문제와 가상 네트워크 어댑터 문제를 한꺼번에 점검하지 않도록 합니다.
  3. 다른 VPN, 가상 네트워크 어댑터, 프록시 도구가 기본 경로를 동시에 가져가고 있지 않은지 확인하세요. TUN을 켠 뒤에는 연결 기록과 시스템 네트워크가 정상인지 살펴보세요.

9. 시작 프로그램에 등록했는데 왜 매번 수동으로 연결해야 하나요?

로그인 후 클라이언트 실행, 코어 실행, 설정 복원, 프록시 활성화는 각각 별개의 과정입니다. 일부 클라이언트는 창이나 트레이 프로세스만 복원하고 시스템 프록시는 자동으로 켜지 않습니다. 서비스 모드라고 해서 사용자가 로그인할 때 그래픽 인터페이스가 반드시 실행되는 것도 아닙니다.

Windows 11에서는 시스템 “설정” → “앱” → “시작 프로그램”에서 클라이언트 시작 항목을 확인하거나, “작업 관리자” → “시작 앱”에서 상태를 볼 수 있습니다. 클라이언트에 “코어 시작”, “이전 상태 복원” 같은 옵션이 있는지는 제품별로 확인하세요. 다른 클라이언트의 메뉴 경로를 그대로 적용하면 안 됩니다.

창을 닫았다가 다시 여는 대신 완전히 재부팅해 확인하세요. 로그인 후 네트워크 연결이 늦어지는 환경에서는 첫 구독 업데이트가 실패해도 반드시 재설치할 필요는 없습니다. 네트워크가 연결된 뒤 직접 업데이트하고 로그를 확인하면 원인을 더 쉽게 찾을 수 있습니다.

10. 첫 주에는 어떻게 관리하고, 문제가 생기면 어떻게 복구하나요?

정상 작동하는 설정을 보관하고 한 번에 한 종류의 설정만 바꾼 뒤 같은 요청으로 다시 확인하세요. DNS, 모드, TUN, 노드를 동시에 바꾸면 비교 기준이 사라집니다. 연결이 복구되더라도 어떤 변경이 효과가 있었는지 알기 어렵습니다.

  1. 기준 상태 기록: 클라이언트 이름, 코어 버전, 현재 Profile, 수신 포트, 프록시 모드를 기록하세요. 버전은 클라이언트의 “정보” 또는 코어 정보 페이지에서 확인하고 설치 파일 이름만 기록하지 마세요.
  2. 업데이트 관리: 서비스 제공업체의 안내에 맞춰 구독 업데이트 주기를 설정하세요. 업데이트가 실패하면 네트워크와 반환 내용을 먼저 확인하고, 짧은 간격으로 계속 재시도하지 마세요.
  3. 단계별 변경: 먼저 노드를 바꾸고 같은 요청을 테스트하세요. 규칙을 조정해야 한다면 규칙 하나만 변경한 뒤 연결 기록에서 해당 규칙이 적용됐는지 확인하세요.
  4. 복구 방법 마련: 설정을 수정하기 전에 백업하세요. 작동하는 Profile로 전환한 뒤에도 클라이언트가 전역 오버라이드를 적용하고 있는지 확인하세요.
  5. 정상 종료: 먼저 시스템 프록시를 끈 다음 클라이언트를 종료하세요. TUN 사용자는 트래픽 가로채기가 완전히 중지됐는지도 확인해야 앱이 더 이상 존재하지 않는 로컬 포트로 접속하지 않습니다.

종료 후 브라우저에서 인터넷에 접속할 수 없다면 Windows 11에서는 “설정” → “네트워크 및 인터넷” → “프록시”의 수동 프록시 설정을 확인하세요. macOS에서는 “시스템 설정” → “네트워크” → 현재 네트워크 서비스 → “세부사항” → “프록시”를 확인할 수 있습니다. 조직에서 관리하는 기기의 설정은 임의로 변경하지 마세요. 명령줄에서 계속 문제가 발생하면 터미널에 프록시 환경 변수가 남아 있는지도 확인하세요.

첫 주 점검 기준은 명확합니다. 설정을 정상적으로 적용할 수 있고, 명시적 프록시 요청이 성공하며, 앱이 의도한 경로를 사용하고, 재부팅 후 상태가 복원되고, 종료 후에는 직접 연결이 정상이어야 합니다. YAML 항목을 하나씩 확인하려면 설정 항목 설명을, 설치와 가져오기 절차는 입문 가이드를 참고하세요.