V2Ray 전체 플랫폼
설치 및 설정 가이드

공통 준비 사항: 시스템·아키텍처·설정 출처

설치 대상과 클라이언트 역할 확인

V2Ray는 프록시 생태계의 기술을 가리키며, 특정 그래픽 인터페이스를 뜻하지 않습니다. 클라이언트는 서버 정보를 저장하고 구독을 업데이트하며 설정을 생성하고 코어를 실행합니다. 실제 프로토콜 통신과 인바운드 수신, 라우팅 처리는 코어가 담당합니다. v2rayN은 Windows·macOS·Linux 데스크톱용이며 v2rayNG와 v2flyNG는 Android용입니다. 먼저 플랫폼을 확인한 뒤 설치 패키지를 선택하세요. 데스크톱 프로그램을 휴대폰에 압축 해제해 실행할 수 없으며, Android 설정 화면의 버튼을 데스크톱에서의 조작 경로로 착각해서도 안 됩니다.

설치 전에 운영체제, 프로세서 아키텍처, 사용할 패키지 형식을 기록해 두세요. Windows에서는 ‘설정 → 시스템 → 시스템 정보’에서 시스템 종류를 확인할 수 있습니다. macOS에서는 ‘이 Mac에 관하여’에서 칩을 확인하세요. Linux에서는 아래 명령으로 시스템 아키텍처와 배포판을 확인하고, Android에서는 기기 사양이나 설치된 앱의 아키텍처 정보를 살펴보면 됩니다. 프로세서의 마케팅 명칭보다 운영체제가 지원하는 아키텍처가 중요하며, 특히 호환 계층을 사용하거나 오래된 시스템을 실행하는 기기에서는 더욱 그렇습니다. 다운로드 페이지에 표시된 항목을 기준으로 패키지를 고르고, 파일 이름만 보고 추측하지 마세요.

uname -m
cat /etc/os-release

Linux에서 x86_64가 출력되면 보통 x64를, aarch64가 출력되면 보통 arm64를 선택합니다. 배포판 정보는 deb 또는 rpm을 고르는 데 쓰이며 프로세서 아키텍처를 판별하는 기준은 아닙니다. macOS에서는 Apple Silicon이 arm64, Intel이 x64에 해당합니다. Android용 arm64 패키지는 해당 앱 아키텍처를 지원하는 시스템에서만 사용할 수 있습니다. 확실하지 않다면 먼저 Android 다운로드 안내를 읽고 범용 버전을 검토하세요.

가져올 연결 정보 준비

클라이언트를 설치해도 사용할 수 있는 서버가 자동으로 만들어지지는 않습니다. 신뢰할 수 있는 설정 제공자가 발급한 단일 공유 링크 또는 구독 URL을 준비하고, 아직 유효한 정보인지 확인하세요. 공유 링크는 단일 설정을 설명하며 구독 URL은 여러 설정을 가져오는 데 사용하므로 입력란을 서로 바꿔 쓸 수 없습니다. 구독 URL에 접근 자격 정보가 포함될 수 있으니 민감 정보로 취급해 보관하세요. 스크린샷·로그·문의 글에는 전체 주소와 사용자 식별 정보, 인증 항목을 남기지 마세요.

제공자가 여러 프로토콜이나 전송 방식을 안내했다면 클라이언트 코어와 호환되고 설명이 명확한 항목부터 사용하세요. 주소·포트·프로토콜·인증 정보·TLS 설정·전송 매개변수가 함께 연결 조건을 구성하므로 서버 도메인만 복사해서는 안 됩니다. 브라우저에서 도메인이 열린다고 프록시 설정이 올바르다는 뜻도 아닙니다. 초보자라면 명확한 단일 설정으로 기본 연결을 확인한 뒤 구독을 추가하세요. 그러면 구독 가져오기 문제와 실제 연결 문제를 구분하기 쉽습니다.

기본 환경을 기록하고 변경을 한 번에 하나씩 진행

설치 전에 기존 프록시 앱, 시스템 프록시 상태, 네트워크 인터페이스, 가상 네트워크 도구 사용 여부를 기록하세요. 첫 테스트에서는 클라이언트 하나만 실행해 여러 프로그램이 시스템 프록시·수신 포트·기본 라우트를 두고 충돌하지 않도록 합니다. 회사 기기의 보안 정책, 관리형 네트워크의 접속 규칙, 로컬 방화벽이 가상 인터페이스나 백그라운드 수신을 제한할 수 있으므로 먼저 필요한 권한을 확인하세요. 모든 보호 기능을 끄는 것을 설치 절차로 삼아서는 안 됩니다.

시스템 시간도 연결 조건의 일부입니다. 시간 오차는 인증서 유효기간 확인과 일부 인증 절차에 영향을 줄 수 있으므로 시스템 자동 시간 설정을 먼저 켜세요. 설치 전 네트워크 상태와 설정 백업을 보관하고, 변경 전에는 기존 값을 기록하세요. 백업에 서버 인증 정보가 포함되어 있다면 본인만 접근할 수 있는 곳에 보관하고 공개 첨부 파일로 올리지 마세요. 준비가 끝나면 해당 플랫폼 섹션을 확인하세요. 시스템 프록시와 TUN을 처음부터 동시에 적용할 필요는 없습니다.

macOS: 칩 확인·설치·네트워크 권한

칩에 맞는 v2rayN 설치 패키지 선택

‘이 Mac에 관하여’에서 칩 정보를 확인한 다음 macOS 다운로드로 이동하세요. Apple Silicon은 arm64, Intel은 x64 항목을 사용합니다. 화면 크기나 구매 연도로 아키텍처를 추측하지 마세요. 호환 환경에서 다른 아키텍처 앱을 실행할 수 있는 경우도 있지만, 기본 아키텍처에 맞는 패키지를 사용하면 실행 종속성과 권한 문제를 파악하기 쉽습니다. 다운로드한 dmg를 열고 창의 안내에 따라 앱을 ‘응용 프로그램’ 폴더에 넣으세요.

복사가 끝나면 디스크 이미지에서 계속 실행하지 말고 ‘응용 프로그램’ 폴더에서 v2rayN을 실행하세요. 디스크 이미지는 배포용이므로 마운트를 해제하면 내부 경로가 사라지고 앱 저장이나 업데이트에 영향을 줄 수 있습니다. 첫 실행 때 시스템 보안 알림이 표시되면 파일 출처와 알림 내용을 확인한 뒤 시스템이 제공하는 절차에 따라 권한을 부여하세요. 앱 하나 때문에 시스템 전체의 보안 검사를 끄거나 출처를 알 수 없는 권한 변경 명령을 붙여 넣지 마세요.

앱이 실행되면 설정을 저장할 수 있는지, 코어가 정상적으로 시작되는지 확인하세요. 화면은 열리지만 함께 제공된 실행 파일이 권한이나 아키텍처 문제로 실행되지 않으면 로그가 시작 단계에서 멈추는 경우가 많습니다. 이때는 원격 서버 매개변수를 바꾸기보다 로컬 실행 문제부터 해결하세요. 시스템 업데이트 후 기존 권한이 바뀌었다면 안내를 다시 확인하세요. 예전 컴퓨터의 권한 상태를 그대로 복사해서는 안 됩니다.

설정 가져오기 및 네트워크 서비스 프록시

공유 링크를 복사해 클라이언트의 클립보드 메뉴에서 가져오거나, 구독 그룹에 구독 URL을 저장하고 업데이트하세요. macOS 클립보드에 이전 내용이 남아 있을 수 있습니다. 가져오기에 실패하면 전체 링크가 복사됐는지, 설명 문구나 줄바꿈이 붙지 않았는지 확인하세요. 가져온 뒤 현재 설정을 선택하고 코어를 시작하세요. 테스트에는 시스템 프록시를 명시적으로 읽는 앱 하나를 사용하고, 자체 프록시 설정이 있는 브라우저 확장 프로그램은 동시에 켜지 않는 편이 좋습니다.

시스템 프록시는 보통 특정 네트워크 서비스와 연결됩니다. Wi-Fi와 유선 네트워크의 프록시 상태가 다를 수 있으므로 네트워크를 바꾼 뒤에는 클라이언트 메뉴만 보지 말고 현재 사용 중인 서비스를 확인하세요. 시스템 네트워크 설정에서 활성 네트워크 서비스의 프록시 항목을 열고 주소와 포트가 클라이언트의 실제 수신 값과 일치하는지 살펴보세요. 자동 프록시 스크립트를 사용한다면 수동 프록시와 스크립트의 적용 순서도 확인해야 합니다.

시스템이 프록시 설정 변경 권한을 요청하면 현재 클라이언트에서 나온 요청인지 확인한 뒤 승인하세요. 권한을 거부해도 코어의 로컬 수신은 가능할 수 있지만 앱이 해당 프록시 진입점을 자동으로 사용하지는 않습니다. 앱 내부에 프록시 주소를 직접 입력해 연결 경로를 확인할 수 있습니다. 연결이 정상임을 확인한 뒤 시스템 설정을 처리하면 ‘시스템 프록시를 쓸 수 없음’과 ‘코어가 서버에 연결하지 못함’을 별개의 문제로 구분할 수 있습니다.

TUN·DNS·절전 모드 복귀

TUN 모드 사용 가능 여부는 현재 클라이언트 빌드, 코어 기능, 시스템 권한에 따라 달라집니다. 사용 전에 현재 네트워크 서비스와 DNS 설정을 기록하고, 다른 가상 네트워크 도구의 트래픽 가로채기를 끄세요. 화면에서 권한 상승이나 보조 구성 요소 설치를 요구하면 현재 버전의 안내를 따르세요. 다른 플랫폼의 드라이버 설치 절차를 macOS에 그대로 적용하지 마세요. 활성화 후 도메인 접속과 로컬 네트워크 리소스를 모두 확인해 분할 라우팅이 원래 직접 연결해야 할 경로를 바꾸지 않았는지 살펴보세요.

DNS 문제는 특정 앱에서만 나타날 수도 있습니다. 브라우저의 보안 DNS 기능이 켜져 있으면 시스템이나 클라이언트가 지정한 경로를 사용하지 않을 수 있습니다. 따라서 브라우저 하나에서 실패했다고 모든 DNS가 작동하지 않는다고 단정하지 마세요. 다른 앱과 비교한 뒤 클라이언트 로그에서 도메인 조회와 연결 단계를 확인하세요. 인증서가 있는 웹사이트에 IP 주소로 접속하면 인증서 일치 조건이 달라지므로 동일한 TLS 테스트로 볼 수 없습니다.

scutil --proxy
scutil --dns

이 읽기 전용 명령 두 개는 현재 프록시와 DNS 정보를 표시하므로 그래픽 설정과 비교하는 데 쓸 수 있습니다. 출력에 회사 설정이나 로컬 네트워크 정보가 포함될 수 있으니 공유하기 전에 민감한 내용을 지우세요. 절전 모드에서 복귀하거나 핫스팟을 바꾸거나 네트워크 서비스를 전환한 뒤에는 기존 연결이 잠시 끊길 수 있습니다. 먼저 연결을 다시 설정하고 서비스 상태를 확인한 다음 코어를 재시작하세요. 처음부터 앱 데이터 폴더 전체를 삭제할 필요는 없습니다.

종료 및 업데이트 후 재확인

종료하기 전에 클라이언트가 변경한 프록시 상태를 복구하세요. 프로그램이 비정상 종료되면 현재 네트워크 서비스에 로컬 프록시가 남아 브라우저가 더 이상 존재하지 않는 수신 포트로 연결할 수 있습니다. 클라이언트를 다시 실행해 상태를 복구하거나 시스템 설정에서 이번에 추가한 프록시 항목만 제거하세요. 기존 회사 설정을 덮어쓰지 않도록 주의해야 합니다. 업데이트 후에는 앱 경로·권한·현재 설정·라우팅 프리셋을 확인하세요. 칩 아키텍처까지 바꿨다면 해당 패키지를 새로 다운로드하고 이전 실행 파일을 그대로 옮기지 마세요.

Android: v2rayNG 및 v2flyNG 설정

클라이언트·아키텍처·설치 권한 선택

Android에서는 Xray 코어 계열인 v2rayNG를 우선 사용하세요. V2Fly 코어 설정이 필요하면 v2flyNG를 고려할 수 있습니다. 이름만 비교하기보다 설정에 필요한 기능과 기존 사용 방식을 기준으로 선택하세요. 두 앱은 설정과 앱 옵션을 각각 저장하며, 하나를 설치해도 다른 앱의 데이터가 자동으로 옮겨지지 않습니다. 먼저 Android 다운로드에서 패키지 항목과 시스템 요구 사항을 확인하세요.

arm64 앱 아키텍처를 지원하는 기기라면 보통 arm64 패키지를 선택합니다. 아키텍처를 모르거나 설치 프로그램에서 호환되지 않는다고 표시되면 범용 버전 안내를 확인하세요. 설치 패키지를 읽지 못하는 원인은 다운로드 미완료·지원되지 않는 시스템 버전·기존 설치 앱과의 서명 불일치일 수도 있으므로 아키텍처 문제로만 단정하지 마세요. 현재 다운로드 출처에서 앱 설치를 허용할 때는 실제 사용하는 출처에만 권한을 부여하고 설치가 끝나면 회수할 수 있습니다.

시스템에서 업데이트 서명 충돌을 알리면 기존 클라이언트를 바로 삭제하지 마세요. 먼저 기존 앱의 출처를 확인하고 복구 가능한 설정을 내보내세요. 앱을 삭제하면 그룹·수동 항목·앱별 분할 라우팅 설정이 사라질 수 있습니다. 내보낸 파일에는 연결 인증 정보가 포함되므로 안전한 곳에 보관하세요. 출처를 확인하지 않고 덮어쓰기보다 같은 출처에서 올바른 패키지를 다시 다운로드하는 편이 문제를 파악하기 쉽습니다. 다른 출처의 패키지를 바로 업데이트할 수 있는지는 시스템 알림을 따르세요.

클립보드 및 구독 그룹에서 가져오기

단일 공유 링크는 클립보드에서 가져오고, 구독 URL은 구독 설정에서 새 항목을 만든 뒤 저장하고 업데이트하세요. Android에서 클립보드 내용이 자동으로 지워질 수 있으므로 복사 후 바로 클라이언트로 이동해 내용이 비어 있거나 웹페이지 안내 문구가 아닌지 확인하세요. 첫 업데이트가 실패하면 주소 형식·연결·응답·파싱 중 어느 단계의 오류인지 기록한 다음, 구독을 가져올 때 기존에 작동하는 설정을 거쳐야 하는지 판단하세요.

목록에서 현재 사용할 설정을 선택하고 연결을 누르세요. 로컬 VPN 터널을 처음 만들 때 Android 시스템에 권한 대화상자가 표시됩니다. 이는 Android 클라이언트가 트래픽을 처리하는 데 필요한 시스템 인터페이스입니다. 승인한 뒤 클라이언트 연결 상태와 시스템 알림을 확인하고 앱 하나로 테스트하세요. 시스템에 VPN 표시가 나타나는 것은 터널이 만들어졌다는 뜻일 뿐 원격 연결이나 도메인 조회가 성공했다는 뜻은 아닙니다.

구독 업데이트는 제공자가 반환한 내용에 따라 항목을 새로 고칩니다. 구독 항목을 직접 수정하면 다음 업데이트에서 변경 사항이 사라질 수 있습니다. 계속 유지할 설정은 별도 항목으로 복사하고 원래 출처를 기록하세요. 클라이언트마다 같은 공유 형식의 지원 여부가 다를 수 있으며, 특히 최신 전송 필드가 포함된 설정에서 차이가 큽니다. 가져오기에 성공해도 프로토콜·TLS·전송 방식과 필요한 매개변수가 모두 들어 있는지 확인하세요.

앱별 분할 라우팅 및 백그라운드 실행

Android 클라이언트는 주로 시스템 VPN 인터페이스를 사용하므로 데스크톱의 시스템 HTTP 프록시 절차를 그대로 적용할 필요가 없습니다. 시스템은 보통 같은 인터페이스를 동시에 점유하는 VPN 서비스를 하나만 허용합니다. 같은 인터페이스를 사용하는 다른 도구가 현재 연결을 대체할 수 있습니다. 테스트할 때는 트래픽을 처리하는 프로그램 하나만 남겨 연결 버튼이 성공으로 표시된 직후 다른 서비스가 연결을 가져가는 일을 막으세요.

앱별 분할 라우팅을 설정할 때는 현재 모드가 ‘선택한 앱만 프록시 사용’인지 ‘선택한 앱 우회’인지 먼저 확인하세요. 두 목록은 의미가 반대이므로 같은 앱을 선택해도 결과가 달라집니다. 앱 하나로 먼저 확인한 뒤 목록을 늘리고, 목록을 바꾼 후에는 클라이언트 안내에 따라 다시 연결하세요. 앱별 분할 라우팅과 도메인 라우팅은 서로 다른 계층입니다. 앱을 제외하면 해당 트래픽은 코어의 규칙에 도달하지 않을 수 있습니다.

화면을 끈 뒤 연결이 끊기는 문제는 배터리 최적화·백그라운드 제한·제조사 작업 정리 기능과 관련된 경우가 많습니다. 먼저 클라이언트 알림이 남아 있는지, 프로세스가 종료됐는지 확인하고 시스템 앱 설정에서 필요한 백그라운드 실행을 허용하세요. 처음부터 서버 프로토콜을 바꾸지 마세요. 모바일 네트워크와 Wi-Fi를 전환하면 연결이 다시 만들어집니다. 특정 네트워크에서만 실패하면 같은 설정으로 비교하고 노드와 DNS를 동시에 바꾸지 마세요.

DNS·핫스팟·업데이트 후 확인

시스템 비공개 DNS·브라우저 자체 DNS 조회·클라이언트 DNS 설정이 서로 다른 경로를 만들 수 있습니다. 도메인에 접속할 수 없다면 먼저 로그를 살펴보고 연결을 끈 상태의 조회 결과와 비교하세요. 무작위 DNS 주소를 하나씩 바꾸는 방식을 고정 해결책으로 삼지 마세요. 핫스팟에 연결된 다른 기기가 휴대폰 클라이언트의 터널을 자동으로 사용하는 것도 아닙니다. 휴대폰 앱이 정상이라고 핫스팟 기기도 같은 경로를 사용한다고 볼 수 없습니다.

클라이언트를 업데이트한 뒤 현재 항목·앱별 분할 라우팅 목록·라우팅 모드·백그라운드 권한을 확인하세요. 시스템 업데이트로 일부 권한이 초기화될 수 있으므로 다시 살펴봐야 합니다. v2rayNG와 v2flyNG의 설정 이름은 다를 수 있습니다. 마이그레이션할 때는 기능별로 대응시키고 구독만 가져왔다고 모든 동작이 같아졌다고 생각하지 마세요. 클라이언트 선택 정보는 클라이언트 3종 비교에서, 첫 연결 절차는 빠른 시작 가이드에서 확인할 수 있습니다.

프록시 및 라우팅: 진입점·출구·규칙 순서

먼저 트래픽이 코어에 들어오는지 확인

라우팅 규칙은 코어에 들어온 트래픽만 처리합니다. 시스템 프록시는 앱에 로컬 프록시 진입점을 제공하고, TUN은 가상 인터페이스로 조건에 맞는 네트워크 트래픽을 처리합니다. Android의 앱 목록은 어떤 앱이 터널에 들어갈지 결정할 수 있습니다. 앱이 클라이언트를 전혀 사용하지 않는다면 routing을 수정해도 동작은 달라지지 않습니다. 분할 라우팅을 진단하기 전에 앱의 진입점과 로컬 수신 설정이 일치하는지 확인한 뒤 규칙을 살펴보세요.

클라이언트의 ‘전역’은 보통 클라이언트에 들어온 트래픽을 하나의 출구로 보내는 의미이며, 기기의 모든 프로그램을 자동으로 강제 처리한다는 뜻은 아닙니다. ‘중국 우회’, ‘블랙리스트’, ‘화이트리스트’ 같은 이름은 클라이언트의 프리셋이며 실제 동작은 생성된 규칙과 출구에 따라 달라집니다. 프리셋 이름만 보고 모든 도메인의 경로를 추측하지 마세요. 같은 이름의 프리셋도 클라이언트나 버전에 따라 규칙이 다를 수 있습니다.

로컬 HTTP·SOCKS·혼합 인바운드는 트래픽을 코어에 전달하고, outbounds는 사용할 출구를 정의하며 routing.rules는 일치하는 대상을 출구 라벨에 연결합니다. 라벨은 참조 관계이지 특별히 예약된 이름이 아닙니다. 규칙의 outboundTag는 실제 출구의 tag와 일치해야 합니다. 그렇지 않으면 설정을 시작하지 못하거나 예상과 다르게 전달될 수 있습니다.

규칙 일치와 예시의 범위

규칙은 보통 순서대로 검사되며 앞쪽에서 일치한 규칙이 뒤쪽의 기본 규칙보다 우선합니다. 너무 앞에 광범위한 규칙을 두면 더 구체적인 규칙이 적용되지 않을 수 있습니다. 도메인 규칙은 명확한 서비스 범위에, IP 규칙은 사설 네트워크나 주소 범위에 적합합니다. 앱이 도메인으로 접속하는지 IP 주소를 직접 사용하는지에 따라 일치시킬 수 있는 정보도 달라집니다. 스니핑이 일부 대상 정보를 보완할 수 있지만 모든 트래픽에서 신뢰할 수 있는 도메인을 복원하는 것은 아닙니다.

아래는 설정 구조를 익히고 로컬 수신을 테스트하는 데 활용할 수 있는 완전한 예시입니다. 직결 및 차단 출구만 정의하며 원격 프록시 서버는 포함하지 않습니다. 모든 인바운드 트래픽은 기본적으로 직결되고, 문서용 예시 도메인에 대한 연결은 차단됩니다. 실행하기 전에 포트가 사용 중인지 확인하세요. 이 예시는 필드 관계를 이해하기 위한 것이므로 이미 작동하는 서버 설정을 덮어쓰는 데 사용하지 마세요. 전체 설정을 가져올 수 있는지는 현재 클라이언트 화면의 메뉴를 확인하세요.

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": [
          "10.0.0.0/8",
          "172.16.0.0/12",
          "192.168.0.0/16",
          "127.0.0.0/8"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

domain:example.com은 예시 도메인과 하위 도메인을 일치시킵니다. 호스트 이름을 정확히 일치시키려면 full: 형식을 사용할 수 있습니다. 규칙에 일치하지 않는 트래픽은 보통 첫 번째 아웃바운드를 사용하므로 이 예시는 직결을 첫 번째에 배치합니다. 프록시 분할 라우팅을 구성하려면 실제로 작동하는 프록시 출구를 별도로 정의하고 해당 규칙에서 출구를 참조해야 합니다. proxy라는 라벨만 추가한다고 프록시 기능이 생기는 것은 아닙니다.

도메인 전략·데이터 파일·DNS

IPIfNonMatch는 도메인 규칙이 일치하지 않을 때 대상 도메인을 조회해 IP 규칙을 추가로 확인할 수 있다는 뜻입니다. 모든 요청에서 먼저 IP를 조회한다는 의미는 아닙니다. AsIs와 IPOnDemand는 조회 시점이 다르며 선택에 따라 일치에 사용할 정보와 DNS 요청이 달라집니다. 설정이 익숙하지 않다면 클라이언트 프리셋을 유지하고 로그로 문제를 확인하세요. 도메인 전략을 일반적인 속도 향상 옵션처럼 사용하지 마세요.

geosite:cn·geoip:cn·geoip:private는 코어에서 읽을 수 있는 데이터와 분류 이름에 의존합니다. 모든 설정에 이 데이터가 기본 제공되는 것은 아닙니다. 파일이나 분류가 없으면 클라이언트가 지원하는 리소스 업데이트 방법을 따르세요. 위 예시는 외부 분류에 의존하지 않도록 사설 네트워크 범위를 명시했지만, 직결해야 할 모든 주소를 포함하지 않으며 IPv6 사설 범위도 설정하지 않았습니다. 따라서 완전한 운영용 분할 라우팅 템플릿으로 바로 사용할 수 없습니다.

규칙이 실제로 적용되는지 확인

한 번에 규칙 하나만 추가하고 재시작하거나 다시 불러온 뒤 코어가 정상적으로 시작되는지 확인하세요. 그다음 목적이 분명한 대상 하나를 테스트합니다. 웹페이지가 열리는지만 보지 말고 연결 로그의 대상·인바운드 라벨·아웃바운드 라벨을 대조하세요. 웹사이트는 여러 도메인에 요청할 수 있으므로 첫 화면이 열린다고 모든 리소스가 같은 경로를 사용한다고 볼 수 없습니다. 확인한 뒤 규칙의 목적과 순서를 기록해 두면 프리셋 업데이트 후에도 기존 규칙을 이해하기 쉽습니다.