Clash 입문부터 고급까지설치·구독·규칙 기반 라우팅

단계 01 / 연결 경로 이해하기

핵심 개념: 클라이언트, 커널, 설정

홈 화면의 스위치부터 살펴보기

Clash 계열 클라이언트를 열면 보통 설정, 프록시, 로그, 시작 스위치를 볼 수 있습니다. 처음부터 여러 화면을 동시에 변경하지 마세요. 클라이언트는 버튼과 알림, 시스템 권한을 제공하는 앱이고, 커널은 규칙을 읽고 연결을 생성해 요청을 전달하는 프로그램입니다. mihomo는 Clash 생태계에서 널리 쓰이는 커널이지 특정 화면 앱을 가리키는 말은 아닙니다. 같은 설정이라도 클라이언트에 따라 다른 커널이나 시작 옵션으로 실행될 수 있으므로 화면이 비슷하다고 모든 기능이 같은 것은 아닙니다.

설정 파일은 네트워크 처리 방법을 적어 둔 문서이며, 보통 YAML 형식으로 작성합니다. YAML은 들여쓰기로 계층을 표현하므로 공백 위치도 내용의 일부입니다. 설정에는 프록시 노드, 정책 그룹, 도메인 해석 방식과 라우팅 규칙을 저장할 수 있습니다. 구독은 이런 정보를 받아오는 경로로, 흔히 링크 형태입니다. 링크에서 내려받는 내용은 전체 설정일 수도 있고 노드 목록일 수도 있습니다. 바로 가져올 수 있는지는 링크 이름에 Clash가 들어 있는지가 아니라 클라이언트가 형식을 인식하는지에 달려 있습니다.

노드, 정책 그룹, 규칙 구분하기

노드는 서버 주소, 포트, 프로토콜과 필요한 인증 정보로 구성된 프록시 접속 지점입니다. 정책 그룹은 여러 출구 중 하나를 선택하며, 수동 선택, 테스트 결과에 따른 선택, 장애 전환 등이 가능합니다. 규칙은 이번 요청을 어떤 출구로 보낼지 결정합니다. 규칙이 요청을 정책 그룹으로 보내면 그룹이 노드를 선택하고, 규칙이 직접 연결을 지정하면 원격 프록시 노드를 거치지 않습니다. 노드만 바꿔도 규칙이 이미 직접 연결로 판단한 요청에는 변화가 없을 수 있습니다.

한 번의 접속 과정을 순서대로 보면 앱이 요청을 보내고, 시스템이 트래픽을 클라이언트에 전달하며, 커널이 대상 정보를 확인해 규칙에 따라 출구를 정한 뒤 대상 서버나 프록시 서버에 연결합니다. 도메인 해석은 이름을 주소로 바꾸는 과정으로 이 흐름에 포함됩니다. 어느 단계에서든 문제가 생기면 겉으로는 웹페이지가 열리지 않는 현상으로 보일 수 있습니다. 구독을 계속 바꾸기보다 요청이 클라이언트에 들어왔는지 확인하고, 적용된 규칙과 출구 연결 결과를 차례로 살펴보는 편이 원인을 찾기 쉽습니다.

기기의 VPN 인터페이스와 원격 서비스는 다릅니다

Android에 VPN 아이콘이 표시되면 시스템이 특정 앱에 해당 트래픽을 처리하도록 허용한 것입니다. VpnService는 클라이언트가 트래픽을 받아 처리할 때 사용하는 로컬 VPN 인터페이스입니다. 아이콘은 기기의 인터페이스가 작동 중임을 보여줄 뿐, 구독이 유효하거나 노드가 사용 가능하거나 대상 사이트에 접속할 수 있다는 뜻은 아닙니다. 프록시 서비스가 시작된 것과 원격 서버 연결에 성공한 것은 서로 다른 확인 단계이며, 뒤의 검증 절차에서 각각 확인합니다.

시스템 프록시도 혼동하기 쉬운 개념입니다. 데스크톱 시스템 프록시는 앱에 프록시 주소를 제공하며, 앱이 이를 따를지는 앱에 달려 있습니다. 가상 네트워크 인터페이스 방식은 더 낮은 네트워크 계층에서 트래픽을 받습니다. Android 클라이언트에는 VPN에 포함할 앱을 지정하는 기능이 있을 수도 있습니다. 브라우저는 접속되는데 다른 앱은 실패한다면 우선 트래픽 처리 범위와 앱 자체의 네트워크 설정을 확인하세요. 브라우저의 결과만으로 기기 전체의 트래픽 경로를 판단할 수는 없습니다.

이 가이드는 해당 기능을 지원하는 mihomo 계열 클라이언트를 중심으로 설명합니다. 예제 필드의 지원 여부는 실제 커널과 클라이언트의 설정 처리 방식에 따라 달라집니다. GUI 클라이언트는 시작할 때 필드를 추가하거나 파일에 있는 같은 이름의 값을 덮어쓸 수 있습니다. 따라서 설정을 점검할 때는 저장된 원본 파일뿐 아니라 앱이 실제로 불러온 실행 설정도 확인해야 합니다. 이 차이를 이해하면 파일을 수정했는데도 실행 동작이 바뀌지 않는 이유를 설명할 수 있습니다.

단계 02 / 기기와 필요한 기능 정하기

클라이언트 선택: 플랫폼, 아키텍처, 커널 기능

플랫폼을 먼저 고르고 기능을 비교하세요

클라이언트 다운로드 페이지에서 기기 운영체제를 먼저 선택한 다음 설치 안내를 확인하세요. Android에서는 Clash Plus를 우선 추천하며, 설정 호환성을 고려해 Clash Meta for Android, FlClash 또는 Surfboard를 선택할 수도 있습니다. 추천 앱이라고 해서 다른 클라이언트의 설정을 그대로 사용할 수 있는 것은 아닙니다. 특히 Surfboard는 Clash YAML과 다른 설정 체계를 사용하므로 파일 확장자만 바꿔서는 변환되지 않습니다. 서비스 제공업체의 설정을 이미 받았다면 지원 클라이언트와 구독 형식을 먼저 확인하세요.

클라이언트를 고를 때는 세 가지를 우선 확인하세요. 기기에 설치할 수 있는지, 구독을 인식하는지, 필요한 기능을 지원하는지입니다. 구독을 가져와 노드만 바꾸면 된다면 당장 쓰지 않을 옵션 때문에 전체 설정을 옮길 필요는 없습니다. 규칙 덮어쓰기, 앱별 프록시 또는 특정 DNS 동작이 필요하다면 클라이언트에서 해당 기능을 제공하는지 확인하세요. 화면에 스위치가 있다고 해서 기능의 동작 방식까지 같다는 뜻은 아니므로 설명을 읽고, 스크린샷만으로 호환성을 판단하지 마세요.

설치 패키지 아키텍처를 기기에 맞추세요

Android 설치 패키지 이름에 표시되는 arm64, arm, universal은 서로 다른 프로세서와 실행 환경을 대상으로 빌드되었음을 뜻합니다. 최신 스마트폰 대부분은 64비트 ARM 환경을 사용하지만, 출시 연도만으로 판단할 수는 없습니다. 일부 기기는 시스템 사용자 공간에 별도 제한이 있으므로 시스템 정보나 다운로드 페이지의 안내를 확인하세요. 범용 패키지는 용량이 더 클 수 있으며, 시스템 최소 요구 사항이나 서명 충돌, 기기 정책을 우회할 수 있다는 뜻은 아닙니다.

컴퓨터에서도 프로세서 종류를 구분해야 합니다. Apple Silicon과 Intel용 macOS 빌드는 칩에 맞춰 선택하고, Linux 패키지는 배포판과 형식을 맞추세요. 커널 압축 파일을 일반 GUI 앱처럼 설치해서는 안 됩니다. 다운로드 페이지의 mihomo 커널 항목은 서버, 라우터 또는 명령줄 배포가 필요한 사용자를 위한 것입니다. 보통 휴대폰에서 구독을 가져오는 완전한 화면을 제공하지 않으며, 시스템 트래픽을 처리하도록 필요한 설정을 모두 자동으로 해주지도 않습니다.

마이그레이션 전에 되돌릴 수 있는 상태를 보관하세요

Clash for Windows와 ClashX Meta는 유지 관리가 중단되었으며, 다운로드 페이지에는 기존 환경을 위한 보관용 다운로드 항목이 있습니다. 새로 설치할 때는 계속 관리되는 대안을 우선 고려하세요. 마이그레이션할 때 노드 목록만 내보내지 말고 현재 정책 그룹 선택, 앱별 적용 범위, 로컬 규칙, 시작 설정도 기록하세요. 새 클라이언트가 구독을 읽을 수 있더라도 기존 앱의 시스템 권한이나 배터리 설정까지 이어받지는 않을 수 있으므로 별도로 다시 확인해야 합니다.

비교를 위해 한 기기에 클라이언트를 여러 개 설치할 수는 있지만, 실제 테스트 중에는 네트워크를 처리하는 서비스를 하나만 실행하세요. 두 앱이 시스템 프록시나 VPN 인터페이스를 두고 경쟁하면 결과를 해석하기 어려워집니다. 기존 클라이언트를 먼저 종료하고 같은 출처의 설정을 가져온 다음, 같은 네트워크와 대상에서 시험하세요. 한 번의 페이지 로딩 속도만 비교하지 말고 특정 규칙이 적용됐는지 같은 동작 차이를 기록해야 합니다.

모바일과 컴퓨터에서 같은 구독을 쓸 때는 공통 노드와 규칙을 유지하고 기기별 설정은 각 기기에 남겨 두세요. Android 앱 패키지 이름에 따른 라우팅은 데스크톱 프로세스 규칙을 그대로 대체할 수 없고, 데스크톱 수신 포트도 휴대폰에 복사할 필요가 없을 수 있습니다. 지원이 종료된 클라이언트의 마이그레이션 배경은 mihomo 계열 클라이언트 대안 가이드에서 확인하세요. 이 장을 마치면 현재 앱을 선택한 이유와 사용할 설정 형식을 지원하는지 설명할 수 있어야 합니다.

단계 03 / 기기에 설치하고 권한 설정하기

Android 설치, VPN 권한, 백그라운드 설정

설치 결과부터 확인하기

Android 다운로드에서 기기에 맞는 설치 패키지를 선택하세요. 다운로드가 끝나면 브라우저 다운로드 목록이나 시스템 파일 관리자에서 파일을 엽니다. 이 출처에서 앱을 설치할 수 없다는 메시지가 표시되면 해당 출처의 권한 화면으로 이동해 이번에 사용할 브라우저나 파일 관리자의 설치를 허용한 뒤 돌아와 설치를 계속하세요. 권한은 설치 패키지를 여는 앱에 부여되는 것이지 네트워크 전체에 적용되는 권한이 아닙니다. 설치가 끝난 뒤에는 기기 관리 방식에 따라 이 권한을 취소해도 됩니다.

앱이 설치되지 않았다는 메시지가 나오면 먼저 시스템에 표시된 구체적인 원인을 확인하세요. 저장 공간이 부족하면 여유 공간을 확보하고, 아키텍처나 시스템이 지원되지 않으면 요구 사항에 맞는 빌드를 선택하세요. 같은 이름의 앱이라도 서명이 다르다면 곧바로 기존 앱을 삭제하지 마세요. 설정과 로컬 데이터를 내보내 복원할 수 있는지 확인한 뒤 설치 출처를 바꿀지 결정하세요. 앱을 삭제하면 일반적으로 앱 전용 데이터가 함께 지워지므로 구독 링크, 규칙 덮어쓰기, 정책 그룹 선택을 시스템 백업에서 모두 되찾지 못할 수 있습니다.

처음 실행할 때는 필요한 권한만 처리하세요

클라이언트를 열고 앱 이름과 설정 화면부터 확인하세요. 유효한 설정을 가져온 다음 서비스를 시작합니다. 처음 연결할 때는 보통 Android VPN 연결 요청이 표시됩니다. 요청을 보낸 앱이 현재 조작 중인 클라이언트인지 확인한 뒤 승인하세요. 이 권한은 앱이 로컬 네트워크 인터페이스를 만들도록 허용하는 것으로, 원격 프록시 서비스를 구매해 주지는 않습니다. 요청이 뜨지 않고 시작에 실패하면 다른 VPN, 업무용 프로필 정책, 기기 관리 제한이 연결 생성을 막는지 확인하세요.

시스템은 보통 같은 사용자나 프로필 공간에서 일반 VPN 서비스를 하나만 활성화할 수 있습니다. 다른 프록시, 기업용 네트워크 연결 또는 방화벽 앱이 실행 중이면 새 연결이 기존 연결을 대체하거나 정책에 의해 차단될 수 있습니다. 필요한 서비스를 먼저 정한 뒤 충돌하는 앱을 종료하고 다시 시도하세요. 이 단계에서는 요청이 원격 노드에 도달하지도 않았을 수 있으므로 시작 실패를 노드 시간 초과 탓으로 돌리지 마세요. 먼저 로컬 권한을 처리하고 로그의 연결 기록을 확인해야 합니다.

화면을 잠그면 연결이 끊기는 경우 배터리 및 백그라운드 제한 확인

앱 아이콘을 길게 눌러 앱 정보를 열고 배터리 또는 백그라운드 사용 관리 항목을 찾으세요. 계속 실행해야 한다면 백그라운드 활동 허용이나 제한 없음으로 설정합니다. 메뉴 이름은 시스템에 따라 다를 수 있습니다. 일부 제조사는 자동 시작, 백그라운드 실행 보호, 최근 앱 잠금도 별도로 제공합니다. 각각 역할이 다르므로 하나만 켜고 모두 설정했다고 생각하지 마세요. 설정을 바꾼 뒤 화면이 켜진 상태에서 먼저 확인하고, 잠시 화면을 잠가 알림과 서비스 상태가 유지되는지 살펴보세요.

알림 권한과 VPN 권한은 서로 다릅니다. 알림을 허용하면 서비스 상태를 확인하고 연결을 빠르게 중지하는 데 도움이 되지만, 알림이 숨겨졌다고 서비스가 중단된 것은 아닙니다. 반대로 알림이 계속 보여도 원격 연결이 정상이라는 뜻은 아닙니다. 백그라운드 문제를 조사할 때는 화면을 잠그기 전후의 서비스 스위치, 시스템 VPN 상태, 로그 시간의 연속성을 기록하세요. 시스템이 앱을 종료했다면 다시 열 때 서비스가 재생성되는 경우가 많습니다. 서비스는 계속 실행되는데 접속에 실패한다면 네트워크 전환과 노드 연결을 확인하세요.

설치 후 첫 테스트는 일반 가정용 네트워크에서 하고, 라우터 프록시나 복잡한 업무 네트워크 정책은 동시에 켜지 않는 것이 좋습니다. 먼저 원래 직접 연결되던 사이트를 열고, 이어서 프록시가 필요한 대상을 방문해 결과를 각각 기록하세요. Wi-Fi와 모바일 네트워크를 모두 시험할 때는 한 번에 네트워크만 바꾸고 노드와 설정은 그대로 유지하세요. 그러면 어느 단계에서 실패했는지 분명해져 기기 설치 문제와 현재 네트워크의 제한을 구분하기 쉽습니다.

권한을 설정한 뒤에는 VpnService 권한 및 배터리 최적화 제외 설정 안내에서 제조사별 항목을 추가로 확인할 수 있습니다. 이 장의 완료 기준은 VPN 아이콘 하나가 아닙니다. 설정이 로드되고, 서비스가 시작되며, 기본 접속이 정상이고, 화면을 잠가도 시스템이 바로 종료하지 않아야 합니다. 이 조건을 확인한 뒤 자동 시작을 켜면 기기를 재부팅한 후 발생하는 연쇄 문제를 줄일 수 있습니다.

단계 04 / 업데이트 가능한 설정 출처 만들기

구독 가져오기, 설정 점검, 업데이트 범위

먼저 받은 내용의 종류를 확인하세요

설정 화면에서 새 설정 추가 또는 링크 가져오기를 선택한 뒤 서비스 제공업체가 준 구독 주소를 붙여넣으세요. 저장할 때는 출처를 알아볼 수 있는 로컬 이름을 사용하고 전체 링크를 이름으로 표시하지 마세요. 구독 주소에는 개인 인증 정보가 포함될 수 있으며, 링크에 접근할 수 있는 사람은 노드 설정을 가져갈 수도 있습니다. 스크린샷, 로그 문의, 동기화 메모를 공유할 때는 링크의 식별 매개변수를 숨기세요. 형식 확인을 위해 개인 구독을 낯선 온라인 변환 사이트에 붙여넣지 마세요.

가져온 뒤 다운로드 결과를 확인하고 해당 설정을 현재 설정으로 선택하세요. 목록에 항목이 추가된 것은 내용이 저장됐다는 뜻일 뿐, 실제로 로드됐다는 의미는 아닙니다. 클라이언트에서 선택, 활성화 또는 다시 불러오기를 해야 할 수 있습니다. 그런 다음 프록시 화면에서 예상한 정책 그룹과 노드가 표시되는지 확인하세요. 노드만 있고 규칙이 없다면 노드 목록만 받은 것일 수 있습니다. 웹페이지 본문이나 로그인 화면, 파싱 오류가 보이면 로컬 DNS부터 바꾸지 말고 구독 출처에서 링크의 용도를 확인하세요.

YAML은 구조부터 점검하세요

설정 파싱에 실패하면 오류 줄 번호와 주변 내용을 기록하세요. 탭을 공백 대신 사용했거나, 같은 단계의 들여쓰기가 맞지 않거나, 목록 항목에 하이픈이 빠졌거나, 문자열의 특수 문자를 제대로 처리하지 않은 경우가 흔합니다. 실제 문제보다 뒤쪽을 오류 위치로 표시하기도 합니다. 예를 들어 앞줄의 따옴표가 닫히지 않은 경우입니다. 마지막으로 정상 작동한 사본을 먼저 복원하고 수정한 부분을 하나씩 확인하세요. 전체 설정의 들여쓰기를 일괄 치환하지 마세요.

아래는 구조를 파악하기 위한 최소 직접 연결 설정이며 원격 프록시 노드는 포함하지 않습니다. 이를 통해 커널이 설정을 읽을 수 있는지와 프록시 서비스에 연결할 수 있는지를 구분할 수 있지만, 구독을 대신하지는 않습니다. GUI 클라이언트는 수신 포트와 DNS를 자체 관리할 수 있으므로 전체 설정을 허용하는지 가져오기 전에 확인하세요. 예제를 구독 마지막에 그대로 붙여 같은 이름의 필드가 중복되게 하지 마세요.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
rules:
  - MATCH,DIRECT

혼합 포트는 기기에서 지원하는 프록시 요청을 받고, LAN 접속 차단 설정은 다른 기기가 해당 수신 포트를 사용하는 것을 막습니다. 규칙 모드는 규칙에 따라 접속을 처리하고 로그 수준은 일상적인 상태 확인에 쓰입니다. 마지막 규칙은 앞에서 일치하지 않은 요청을 직접 연결로 보냅니다. 포트를 다른 프로세스가 사용 중이면 커널 시작이 실패할 수 있으므로 문법이 유효하다고 실행 환경까지 적합한 것은 아닙니다. 포트가 충돌하면 해당 프로세스를 종료하거나 클라이언트가 허용하는 수신 포트로 변경하세요.

원격 업데이트와 로컬 수정은 분리하세요

구독을 업데이트하면 원격 설정 내용이 교체되는 경우가 많습니다. 내려받은 파일을 직접 수정하면 다음 업데이트 때 변경 사항이 사라질 수 있습니다. 클라이언트의 덮어쓰기, 병합, 로컬 규칙 기능을 사용해 개인 수정 사항을 별도로 저장하되, 먼저 실행 시점과 병합 규칙을 확인하세요. 어떤 도구는 목록을 추가하고 어떤 도구는 필드 전체를 교체합니다. 병합이라는 이름만 보고 기존 정책 그룹과 규칙 순서가 모두 유지된다고 가정하지 마세요.

업데이트 간격은 출처의 제한과 실제 변경 주기를 고려해 정하세요. 너무 자주 업데이트하면 요청 제한에 걸릴 수 있고, 네트워크가 불안정할 때 실패 알림이 반복될 수도 있습니다. 먼저 수동으로 업데이트해 설정을 다시 불러올 수 있는지 확인한 뒤 정기 업데이트를 켜세요. 업데이트는 실패했지만 기존 설정이 작동한다면 현재 상태를 유지하고 구독 만료, 링크 권한, 다운로드 네트워크를 확인하세요. 목록을 갱신하려고 유일하게 작동하는 설정을 먼저 삭제하지 마세요.

여러 기기를 동기화할 때는 모든 앱 데이터를 덮어쓰기보다 설정 출처와 필요한 개인 규칙을 동기화하는 편이 좋습니다. 휴대폰과 컴퓨터에서 같은 구독을 쓸 수 있지만, 시스템 트래픽 처리, 수신 포트, 앱 적용 범위, 파일 경로는 각 기기에 맞게 유지하세요. 자세한 내용은 휴대폰과 컴퓨터에서 구독을 함께 사용하는 동기화 방법을 참고하세요. 이 장을 마치면 현재 어떤 설정이 로드됐는지, 어디서 업데이트되는지, 어떤 로컬 변경 사항을 따로 백업해야 하는지 알 수 있어야 합니다.

단계 05 / 요청이 향할 출구부터 정하기

Rule, Global, Direct 사용 순서

일상적인 사용에는 규칙 모드부터

클라이언트의 모드 설정을 열고 일상적으로는 Rule, 즉 규칙 모드를 우선 선택하세요. 커널은 설정에 있는 규칙을 순서대로 확인해 직접 연결, 차단 또는 정책 그룹 사용 여부를 결정합니다. 규칙 모드라고 해서 모든 요청이 프록시를 거치거나 브라우저에만 적용되는 것은 아닙니다. 커널에 들어온 요청을 처리하는 모드입니다. 앱이 VPN 적용 대상에서 제외됐거나 데스크톱 프로그램이 시스템 프록시를 사용하지 않는다면, 규칙 모드로 바꿔도 해당 요청이 자동으로 들어오지는 않습니다.

프록시 화면에서 규칙이 실제로 가리키는 정책 그룹을 찾아 사용 가능한 출구를 선택하세요. 설정에는 전체 선택 그룹, 자동 선택 그룹, 서비스별 그룹이 함께 있을 수 있습니다. 그중 하나만 바꿔서는 대상 접속에 영향을 주지 않을 수 있습니다. 로그나 연결 화면에서 해당 요청이 어느 그룹에 일치했는지 확인한 뒤 그 그룹을 조정하세요. 이름이 비슷한 정책 그룹끼리 연결되어 있지 않을 수도 있으므로, 가장 눈에 띄는 버튼이 모든 트래픽의 최종 출구라고 단정하지 마세요.

Global 모드는 비교용이며 트래픽 처리 범위를 확인하는 대신 쓸 수 없습니다

규칙 모드에서 특정 대상에 접속할 수 없다면 잠시 Global로 전환하고 전역 정책 그룹에서 예상한 노드가 선택됐는지 확인한 뒤 같은 대상에 다시 접속하세요. 이때 정상이고 규칙 모드에서만 실패한다면 적용 규칙, 정책 그룹 선택, 도메인 해석 차이를 먼저 확인하세요. 이 결과만으로 원래 규칙이 잘못됐다고 단정할 수는 없습니다. 두 모드가 서로 다른 출구를 함께 사용할 수 있기 때문입니다. 비교할 때 네트워크, 대상, 노드를 그대로 유지해야 변수를 줄일 수 있습니다.

Global 모드라고 해서 기기의 모든 데이터 패킷이 반드시 원격 프록시를 통과하는 것은 아닙니다. 앱 제외 설정, 로컬 라우팅, 시스템 제한, 클라이언트 구현에 따라 트래픽 처리 범위가 달라집니다. Global로 바꾼 뒤에도 로그에 대상 앱 요청이 전혀 없다면 노드를 계속 바꿔도 소용이 없습니다. 이때는 앱이 적용 대상인지, 시스템 VPN이 작동 중인지, 프로그램에 별도 프록시 또는 직접 연결 설정이 있는지 확인하세요. 모드와 트래픽 처리 범위를 구분해서 보는 것이 이 장의 핵심입니다.

Direct 모드와 서비스 중지는 다릅니다

Direct 모드에서는 커널에 들어온 요청이 직접 연결 출구를 사용하지만, 클라이언트의 로컬 인터페이스와 DNS 처리는 계속 동작할 수 있습니다. 서비스를 완전히 중지하면 시스템 네트워크 경로가 달라질 수도 있습니다. 따라서 Direct 모드에서는 되지만 서비스를 중지하면 안 되거나 그 반대인 경우, 인터페이스, 도메인 해석, 시스템의 VPN 우회 차단 설정을 확인해야 합니다. Direct 모드를 모든 네트워크 설정이 원래대로 복구된 상태로 생각하지 말고, 이유를 모르는 채 시스템 VPN 설정을 삭제하지도 마세요.

모드를 바꾼 뒤에는 새 연결을 만들어 확인하세요. 브라우저는 연결을 재사용하고 앱도 장시간 연결을 유지할 수 있으므로, 정책을 바꿔도 기존 연결이 자동으로 다시 만들어지지 않을 수 있습니다. 관련 페이지를 닫았다가 다시 열거나, 클라이언트에서 허용하는 경우 해당 연결만 종료하세요. 연결을 모두 지우면 진행 중인 작업이 중단되므로 먼저 작업을 저장하세요. 오래된 세션을 재사용하는 페이지를 새로고침하는 데 그치지 말고, 새 연결의 출구와 적용 규칙을 확인해야 합니다.

노드 테스트 결과는 특정 테스트 대상과 방식에 대한 결과일 뿐, 모든 사이트에 접속할 수 있다는 뜻은 아닙니다. 실제 요청은 다른 프로토콜, 포트, 주소 계열을 사용할 수 있습니다. 노드를 선택한 뒤 대상 앱에서 실제 요청을 보내고 연결 오류를 확인하세요. 한 앱은 정상인데 다른 앱은 실패한다면 먼저 두 앱이 모두 트래픽 처리 대상인지, 같은 정책 그룹을 사용하는지, 서로 다른 네트워크 기능이 필요한지 비교한 후 노드를 바꾸세요.

비교가 끝나면 규칙 모드로 돌아가 임시 변경 사항을 기록하세요. Global 모드를 계속 사용하면 수정해야 할 라우팅 문제를 놓치거나 직접 연결해야 하는 로컬 서비스가 잘못된 출구를 거칠 수 있습니다. 데스크톱 브라우저와 터미널에서 시스템 프록시가 다르게 작동하는 문제는 시스템 프록시가 적용되지 않을 때 각각 점검하는 방법을 참고하세요. 다음 장에서는 여기서 확인한 적용 결과를 구체적인 규칙과 연결해 살펴봅니다.

단계 06 / 규칙 하나부터 수정하기

규칙 기반 라우팅: 매칭 순서와 로컬 덮어쓰기

새 규칙을 추가하기 전에 기존 규칙부터 찾으세요

로그나 연결 세부 정보 화면을 열고 대상에 한 번 접속해 도메인, 적용된 규칙, 최종 정책을 확인하세요. 규칙은 대개 위에서 아래로 처리되며 처음 일치하는 규칙이 출구를 결정합니다. 따라서 더 구체적인 예외는 일반적인 규칙보다 위에 두는 경우가 많습니다. 기본 규칙 뒤에 추가한 항목은 실행될 기회가 없을 수 있습니다. 수정 전에는 현재 설정에 규칙 모음, 로컬 병합 계층 또는 클라이언트가 자동으로 넣는 규칙이 있는지 확인하세요. 실제 실행 순서가 원본 파일 순서와 다를 수 있습니다.

도메인 완전 일치는 지정한 이름만 대상으로 하고, 도메인 접미사 일치는 해당 도메인과 하위 도메인까지 포함하며, IP 대역 규칙은 대상 주소를 기준으로 합니다. 각각 해결하는 문제가 다르므로 앱 화면에 표시된 브랜드 이름을 곧바로 도메인 규칙으로 사용해서는 안 됩니다. 앱은 여러 도메인에 접속하거나 고정 주소에 연결할 수 있습니다. 로그에서 실제 대상을 확인한 뒤 필요한 범위만 규칙에 적용하세요. 한 페이지 문제를 해결하려고 큰 도메인 범위 전체를 같은 출구로 보내지 마세요.

전체 최소 예제로 규칙 순서 이해하기

아래 예제에는 원격 노드가 없으며, 로컬 도메인, 사설 주소, 기본 규칙의 순서를 보여줍니다. 독립적인 직접 연결 테스트 설정으로 쓸 수 있습니다. 구독에 규칙을 추가하려면 클라이언트의 로컬 규칙 또는 덮어쓰기 메뉴를 사용하고 원래 설정의 나머지 항목은 유지하세요. 예제에는 일부 일반적인 로컬 주소만 포함되어 있습니다. 완전한 사설망 주소 목록이 아니며 특수한 기업 주소 설계에 적합하다고 보장할 수 없습니다.

mode: rule
rules:
  - DOMAIN,localhost,DIRECT
  - DOMAIN-SUFFIX,home.arpa,DIRECT
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,DIRECT

마지막 MATCH 규칙은 앞에서 일치하지 않은 요청을 처리합니다. 실제 구독에서는 프록시 정책 그룹을 가리킬 수 있으므로 수정할 때 설정에 실제로 존재하는 정책 그룹 이름을 사용해야 합니다. 이름이 다르면 참조 오류가 발생합니다. 주소 규칙 뒤의 no-resolve는 해당 규칙과 일치시키기 위해 도메인 조회를 별도로 시작하지 않는다는 뜻이지, 요청 처리 과정의 다른 조회까지 금지한다는 뜻은 아닙니다. 이 범위를 알아야 전체 DNS 스위치로 오해하지 않습니다.

규칙 모음과 정책 그룹은 따로 관리하세요

규칙 모음은 여러 매칭 조건을 관리하고 정책 그룹은 출구 선택을 관리합니다. 둘을 혼동하지 마세요. 규칙 모음 업데이트에 실패해도 노드는 사용할 수 있으며, 노드 구독 업데이트에 성공했다고 원격 규칙까지 갱신된 것은 아닙니다. 규칙 제공자를 점검할 때는 출처 형식, 동작 유형, 다운로드 결과, 로컬 캐시를 확인하세요. 처음 다운로드에 실패한 기기는 이전 캐시가 저장된 기기와 다른 결과를 낼 수 있으므로 마이그레이션 테스트에서 특히 주의해야 합니다.

앱별 라우팅이 필요하다면 먼저 클라이언트가 제공하는 기능이 앱별 VPN 적용 범위인지, 커널의 프로세스 규칙인지 확인하세요. VPN에서 앱을 제외하면 그 앱의 트래픽은 커널에 아예 들어오지 않을 수 있습니다. 앱에 직접 연결 규칙을 적용하면 커널이 계속 처리할 수도 있습니다. 두 방식은 로그에서 보이는 정도와 DNS 동작이 다를 수 있습니다. Android의 앱 식별자와 데스크톱 프로세스 이름은 다르므로 컴퓨터 규칙을 휴대폰에 그대로 복사했다고 적용이 끝난 것은 아닙니다.

한 번에 규칙 하나만 추가하고 저장한 뒤 다시 불러와 새 연결로 확인하세요. 화면에는 성공으로 표시되는데 결과가 바뀌지 않는다면 대상 설정이 로드됐는지, 덮어쓰기가 활성화됐는지, 규칙이 기본 규칙보다 앞에 있는지, 기존 연결을 재사용하는지 순서대로 확인하세요. 이 단계를 확인한 뒤 도메인 인식과 DNS 매핑 문제를 살펴보세요. 중복 규칙을 계속 추가하면 설정을 읽기 어려워지고 다음 업데이트 때 병합 충돌도 늘어날 수 있습니다.

여러 대상에서 같은 오류가 발생하면 각 도메인에 예외를 추가하기 전에 공통 정책 그룹이나 공통 도메인 해석 경로부터 확인하세요. 규칙을 지나치게 세분화하면 실제 출구 문제가 가려질 수 있습니다. 자세한 개념은 Rule 용어 설명에서 확인하고, 자주 발생하는 설정 문제는 FAQ를 참고하세요. 이 장의 완료 기준은 요청이 왜 현재 출구를 사용하는지 설명하고, 되돌릴 수 있는 단일 변경으로 결과를 바꾸는 것입니다.

단계 07 / 트래픽 처리 범위를 넓히기 전에 도메인 해석 이해하기

TUN, VpnService, DNS의 연동 방식

가상 네트워크 인터페이스가 해결하는 문제

TUN은 네트워크 계층의 트래픽을 받는 가상 인터페이스 방식입니다. 데스크톱에서는 시스템 프록시만으로 처리하기 어려울 때 사용합니다. 예를 들어 프로그램이 프록시 설정을 따르지 않거나 브라우저 외의 특정 트래픽을 처리해야 하는 경우입니다. TUN과 Rule, Global은 같은 기준의 옵션이 아닙니다. TUN은 트래픽이 커널에 들어오는 방식을 정하고, Rule과 Global은 들어온 트래픽의 출구를 정합니다. TUN을 켠 뒤에도 규칙 모드를 쓸 수 있으므로 가상 인터페이스를 위해 모든 요청을 전역 프록시로 바꿀 필요는 없습니다.

Android 클라이언트는 보통 VpnService로 시스템 트래픽을 받지만 데스크톱 TUN 옵션을 휴대폰에 그대로 복사해서는 안 됩니다. 모바일에서는 클라이언트가 인터페이스, 라우팅, 파일 디스크립터를 만든 뒤 커널에 넘길 수 있습니다. 데스크톱의 자동 라우팅 설정은 추가 권한과 시스템 명령에 의존할 수 있습니다. 먼저 클라이언트가 제공하는 스위치와 기본값을 사용하세요. 사용자 지정 필드를 지원하는지 확인한 뒤에 조정해야 화면에서 생성한 설정과 직접 작성한 설정이 서로 덮어쓰는 일을 피할 수 있습니다.

라우팅과 권한을 확인한 뒤 활성화하세요

데스크톱에서 가상 인터페이스를 켜면 관리자 권한이나 서비스 권한이 필요할 수 있습니다. 권한을 부여한 뒤 인터페이스가 생성됐는지 확인하고, 일반 사이트, LAN 기기, 프록시 대상에 모두 접속할 수 있는지 살펴보세요. 프록시 노드로 향하는 연결이 다시 가상 인터페이스에 들어가면 루프가 생길 수 있습니다. 다른 VPN과 기본 경로를 동시에 변경하면 일부 트래픽이 잘못된 경로로 갈 수도 있습니다. 문제가 생기면 새로 추가한 트래픽 처리 기능부터 끄고 네트워크를 복구한 뒤 라우팅 제외 설정과 클라이언트 문서를 확인하세요.

LAN 접속은 별도로 검증해야 합니다. 프린터, 라우터 관리 페이지, 네트워크 저장 장치는 로컬 주소, 멀티캐스트 검색, 기기 이름 해석에 의존할 수 있으므로 공용 웹사이트 하나가 열리는지만으로 판단할 수 없습니다. 우선 클라이언트가 권장하는 로컬 라우팅 설정을 유지하고, 제외 항목을 추가해야 하는지 확인하세요. 기기 하나에 잠시 접속하려고 방화벽을 모두 끄거나 전체 LAN에 로컬 프록시 사용을 허용하지 마세요. 이는 별도의 접근 권한 문제입니다.

DNS는 도메인 이름을 주소로 바꾸는 방식입니다

DNS는 도메인 이름 해석 시스템입니다. 브라우저에 이름을 입력하면 접속을 이어가기 위해 주소를 받거나 프록시 측에서 이름을 해석해야 합니다. 도메인 해석에 성공해도 해당 주소에 연결할 수 있다는 보장은 없으며, 연결 실패가 반드시 DNS 오류를 뜻하는 것도 아닙니다. DNS 해석 오류, 연결 시간 초과, 인증 오류를 로그에서 구분한 다음 설정 변경 여부를 결정하세요. 구독을 내려받을 때의 DNS 경로와 프록시 실행 후의 DNS 경로가 다를 수 있으므로 구독 업데이트 실패와 웹 접속 실패가 같은 원인이라고 단정할 수 없습니다.

일부 클라이언트는 fake-ip 모드를 제공합니다. 앱에 매핑용 가상 주소를 먼저 반환한 뒤 커널이 도메인과 연결의 대응 관계를 유지하는 방식입니다. 도메인 정보를 보존하는 데 유용하지만 실제 주소 동작에 의존하는 앱에는 예외 설정이 필요할 수 있습니다. 공용 인터넷 주소가 아닌 결과가 보인다고 곧바로 잘못된 DNS 응답이라고 판단하지 마세요. 이 모드가 활성화됐는지, 요청을 계속 같은 커널이 처리하는지, 앱이 정상적인 도메인 해석 경로를 우회하는지 먼저 확인하세요.

암호화 DNS는 DNS 요청의 전송을 보호하지만 올바른 출구를 자동으로 보장하지는 않습니다. DNS 서버 자체에도 연결할 수 있어야 합니다. 시작 단계에서 아직 준비되지 않은 프록시 경로에 의존하면 DNS 해석이 먼저인지 연결이 먼저인지 꼬일 수 있습니다. 수정할 때는 기본적인 도메인 해석을 할 수 있는 경로를 유지하고 상위 DNS와 라우팅을 차례로 조정하세요. 브라우저의 보안 DNS, 시스템 비공개 DNS, 클라이언트 DNS가 모두 관여할 수 있으므로 실제 활성화 항목을 기록하세요. 설정을 한꺼번에 모두 바꾸지는 마세요.

검증 순서는 인터페이스 존재 여부, 대상 요청의 로그 유입, 도메인 처리, 규칙 적용, 출구 연결로 고정할 수 있습니다. 각 단계가 정상인데 특정 앱만 실패한다면 주소 계열, UDP 지원, 앱 자체의 제한을 확인하세요. 한 번의 웹페이지 테스트만으로 노드가 특정 전송 방식을 지원하는지 판단할 수는 없습니다. 이 장을 마치면 TUN이 필요한 경우를 구분하고, 설정 참조 오류 하나를 고치려고 기기 전체의 가상 인터페이스 설정까지 바꿀 필요가 없다는 점을 이해해야 합니다.

단계 08 / 반복 가능한 유지 관리 절차 만들기

업데이트, 백업, 단계별 문제 해결

세 종류의 업데이트를 구분하세요

클라이언트 업데이트, 커널 업데이트, 구독 업데이트는 각각 다른 작업입니다. 클라이언트 업데이트는 화면, 시스템 권한, 설정 처리 방식을 바꿀 수 있습니다. 커널 업데이트는 지원 필드와 네트워크 동작에 영향을 줄 수 있고, 구독 업데이트는 주로 노드, 정책 그룹, 규칙 내용을 바꿉니다. 세 가지를 한꺼번에 업데이트한 뒤 문제가 생기면 원인을 찾기 어렵습니다. 정기 유지 관리 전 현재 정상 상태를 백업하고 한 번에 하나씩 변경하세요. 각 변경 후 기본 접속을 시험해 정상인지 확인한 뒤 다음 작업을 진행합니다.

백업에는 최소한 설정 출처, 로컬 규칙, 정책 그룹 선택, 시스템 관련 설정이 포함되어야 합니다. 구독 주소나 인증 정보가 포함된 파일은 직접 관리하는 안전한 위치에 저장하고, 공개 문의에는 민감 정보를 가린 일부 내용만 제공하세요. 앱에서 내보낸 백업에는 개인 정보가 포함될 수도 있고 시스템 VPN 권한은 들어 있지 않을 수도 있으므로 복원 전에 내보내기 안내를 확인하세요. YAML 하나를 복원할 수 있다고 기기 전체가 백업된 것은 아닙니다. 배터리 제한과 앱별 적용 목록은 다시 설정해야 할 수 있습니다.

최근 변경 사항과 영향 범위부터 살펴보기

인터넷에 접속할 수 없다면 먼저 언제부터 문제가 시작됐는지, 직전에 무엇을 바꿨는지, 한 앱에만 영향을 주는지 전체 앱에 영향을 주는지 기록하세요. 그런 다음 Wi-Fi와 모바일 네트워크, 직접 연결 대상과 프록시 대상의 차이를 구분합니다. 서비스를 꺼도 기기의 기본 네트워크에 접속할 수 없다면 네트워크 연결이나 로그인 페이지부터 해결하세요. 네트워크 입구가 아직 동작하지 않는 동안 클라이언트에서 노드 테스트를 반복해도 실패 기록만 쌓일 뿐 노드 자체 상태를 판단하는 데 도움이 되지 않습니다.

노드 시간 초과는 특정 연결이 정해진 시간 안에 완료되지 않았다는 뜻이며 서버가 중지됐다는 직접적인 증거는 아닙니다. 구독 만료, 주소 해석 오류, 현재 네트워크 제한, 시스템 시간 오류, 지원되지 않는 프로토콜도 원인일 수 있습니다. 최근에 정상적으로 갱신된 노드 정보인지 확인하고 기기 시간이 자동 동기화되는지 살펴본 뒤 다른 네트워크와 비교하세요. 자세한 점검 순서는 노드 시간 초과 및 전체 연결 실패 체크리스트를 참고하세요. 서버 주소, 포트, 프로토콜을 동시에 바꿔가며 추측하지 마세요.

로그 수준은 구체적인 문제를 확인할 때만 높이세요

평소에는 적절한 로그 수준을 유지하세요. 문제를 추적할 때는 대상 페이지 하나만 여는 식으로 재현 가능한 작업을 준비한 뒤, 잠시 로그 상세도를 높입니다. 문제 기록을 얻으면 원래 수준으로 되돌려 불필요한 로그가 쌓이지 않게 하세요. 공유 전에 도메인, 주소, 구독 매개변수, 인증 정보를 숨겨야 하는지 확인하세요. 마지막 오류 한 줄만으로 판단하기 어려울 수 있지만, 확인하지 않은 전체 실행 로그를 그대로 공개하는 것도 적절하지 않습니다.

로그를 읽을 때는 오류가 발생한 단계를 구분하세요. 주소를 얻기 전에는 DNS 해석 오류가 발생하고, 연결 거부는 상대 서버나 중간 장비가 연결을 명시적으로 거부했다는 뜻입니다. 시간 초과는 제한 시간 안에 연결을 완료하지 못한 상태입니다. 서로 다른 현상을 같은 문제로 취급하지 마세요. 인증서 오류가 있다면 시스템 시간, 서버 이름, 네트워크 환경부터 확인하고 보안 검증을 꺼서 덮으려 하지 마세요. 설정 파싱 오류는 파일 구조를 다시 살펴봐야 하며 실제 네트워크 연결 단계까지 진행되지 않은 경우가 많습니다.

수정할 때마다 특정 규칙을 복원하니 대상에 정상 접속됐다는 식으로 간단한 결론을 기록하세요. 그저 네트워크가 정상화됐다고만 적지 마세요. 이후 구독 업데이트, 화면 잠금 후 복구, 네트워크 전환을 테스트해 다른 상황을 망가뜨리지 않았는지 확인합니다. 최근 정상 작동한 설정 사본과 간단한 변경 기록을 보관하면 다음에 문제가 생겼을 때 확인된 상태로 되돌아가기 쉽습니다. 자주 묻는 화면 문제는 FAQ 분류에서 바로 찾아볼 수 있어 가이드 전체를 반복해 검색할 필요가 없습니다.

단계 09 / 작동하는 설정에서 유지 관리 가능한 설정으로

고급 학습 경로: 검증, 계층화, 최소 변경

먼저 나만의 검증 목록을 만드세요

고급 사용은 모든 기능을 켜는 것이 아니라 현재 동작을 설명하고, 수정 후 결과가 예상대로인지 검증할 수 있는 것입니다. 안정적인 테스트 항목 몇 가지를 정하세요. 직접 연결 사이트, 프록시가 필요한 대상, LAN 접속 경로, 일상적으로 사용하는 앱이 좋습니다. 변경할 때마다 같은 항목을 다시 시험해 트래픽 처리, 규칙, 출구가 일관적인지 확인하세요. 테스트 대상은 실제 사용 목적에 맞춰야 하며, 설정을 완성해 보이게 하려고 쓰지 않는 프로토콜이나 규칙 모음을 추가할 필요는 없습니다.

설정을 계층별로 나눌 때 원격 구독, 로컬 정책, 기기 설정으로 출처를 구분할 수 있습니다. 원격 구독은 노드와 공통 규칙을 관리하고, 로컬 정책은 개인 예외를 소량 저장하며, 기기 설정은 VPN 적용 범위, 수신 포트, 시작 동작을 다룹니다. 각 계층에 명확한 역할을 부여해야 업데이트 때 어느 부분이 바뀌어야 하는지 알 수 있습니다. 같은 DNS 필드를 구독, 덮어쓰기, 클라이언트 화면에서 모두 수정했다면 최종 적용 출처부터 찾고 어느 설정을 유지할지 결정하세요.

커널 검사 기능으로 설정 편집 점검하기

명령줄 사용에 익숙하다면 mihomo의 설정 테스트 기능으로 로컬 파일을 확인할 수 있습니다. 아래 명령은 커널이 설치되어 있고 현재 디렉터리에 설정 파일이 있는 환경에서 실행해야 합니다. 설정을 테스트하는 기능이며 운영체제의 프록시 트래픽 처리를 대신 설정해 주지는 않습니다. Android GUI 클라이언트 사용자는 앱 내 점검과 로그 기능을 이용하면 되므로 명령을 실행하려고 휴대폰에 별도 환경을 설치할 필요는 없습니다.

mihomo -t -f ./config.yaml

검사 성공은 주로 커널이 설정을 읽고 관련 검사를 통과했다는 뜻입니다. 모든 원격 노드 연결, 라우팅, 권한이 정상이라는 보장은 아닙니다. 외부 규칙, 제공자, 리소스 파일을 사용한다면 작업 디렉터리, 상대 경로, 다운로드 조건도 충족되는지 확인해야 합니다. 터미널과 GUI 클라이언트는 서로 다른 디렉터리에서 시작할 수 있습니다. 한 경로에서 읽을 수 있는 로컬 파일이 다른 시작 방식에서도 유효하다고 단정할 수 없습니다.

설정을 편집하기 전에 사본을 저장하고 수정 후 문법을 확인하세요. 그런 다음 클라이언트에서 다시 불러오고 새 요청을 관찰합니다. 문제가 생기면 패치를 계속 덧붙이지 말고 방금 한 단일 변경부터 되돌리세요. 파일을 비교할 때는 필요한 필드만 확인하고 인증 정보는 공개 비교 도구에 붙여넣지 마세요. 구독에서 자동 생성되는 복잡한 설정은 병합 규칙을 이해한 로컬 덮어쓰기를 우선 사용하세요. 보기 좋게 만들려고 이해하지 못한 참조 항목을 임의로 삭제하지 마세요.

원격 관리와 LAN 공유에는 별도 제한이 필요합니다

일부 커널은 대시보드나 클라이언트가 상태를 읽고 정책을 전환할 수 있도록 제어 인터페이스를 지원합니다. 프록시 수신 포트와는 용도가 다릅니다. 일반적인 단일 기기 사용에서는 제어 인터페이스를 모든 네트워크 인터페이스에 열 필요가 없습니다. 원격 관리가 꼭 필요하다면 인증, 네트워크 격리, 방화벽 범위를 함께 고려하세요. 제어 주소, 구독 링크, 권한이 포함된 대시보드 링크를 공개하지 마세요. 브라우저에서 열 수 있는 관리 화면이라고 해서 공개 배포에 적합한 웹사이트인 것도 아닙니다.

LAN 프록시 공유도 별도로 계획해야 합니다. 다른 기기의 접속을 허용하면 이 기기가 네트워크 출구가 되므로 수신 주소, 포트, 허용 대상을 확인해야 합니다. 모바일 핫스팟, 공용 Wi-Fi, 가정용 네트워크의 신뢰 수준은 서로 다르므로 같은 개방 설정을 계속 사용하지 마세요. 공유 전에 통제된 네트워크에서 기기 하나로 검증하고, 공유가 끝나면 허용 범위를 원래대로 돌리세요. 인증 필요 여부와 접근 제한 방법은 현재 클라이언트가 실제로 지원하는 기능을 기준으로 결정해야 합니다.

다음 학습 주제는 해결할 문제에 맞춰 선택하세요

여러 기기의 유지 관리가 중요하다면 구독과 로컬 덮어쓰기를 분리하는 방법을 더 살펴보세요. 앱 호환성이 중요하다면 DNS, 주소 계열, 전송 방식의 관계를 알아보세요. 라우터 배포가 목적이라면 인터페이스, 라우팅, 서비스 관리까지 살펴봐야 합니다. 서버나 라우터의 설정은 부팅 시 서비스 실행, 파일 권한, 네트워크 방화벽도 다룹니다. 휴대폰에서 작동한 설정을 완전한 배포 방식으로 간주해서는 안 됩니다. 복구할 수 있는 환경에서 먼저 검증한 뒤 일상적으로 네트워크를 사용하는 기기에 적용하세요.

마지막으로 사용할 클라이언트, 설정 출처, 로컬에서 바꾼 항목, 정상 여부 확인 방법, 복구 방법을 간단히 기록해 두세요. 이해할 수 없는 매개변수를 길게 나열하는 것보다 이런 안내가 더 유용합니다. 기본 조작을 다시 확인하려면 빠른 시작 가이드로 돌아가세요. 기기를 바꿀 때는 다운로드 페이지에서 플랫폼 요구 사항을 다시 확인하세요. 같은 결과를 재현하고 원인을 찾고 복구할 수 있다면 이 학습 경로를 마친 것입니다.