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

01 / PREPARATION

공통 준비: 플랫폼, 아키텍처 및 설정 출처

먼저 클라이언트, 커널, 구독을 구분하세요

완전한 V2Ray 사용 과정은 세 부분으로 구성됩니다. 그래픽 클라이언트는 인터페이스, 시스템 프록시 전환, 로그와 설정을 관리하고, 커널은 프로토콜을 해석해 아웃바운드 연결을 수립하고 라우팅을 실행하며, 구독 또는 공유 링크는 노드 매개변수를 제공합니다. v2rayN은 Windows, macOS, Linux용 데스크톱 클라이언트로 구독, 라우팅과 시스템 프록시를 통합 관리할 수 있습니다. Android에서는 v2rayNG 또는 v2flyNG를 주로 사용하며, 전자는 Xray 커널 계열, 후자는 V2Fly 커널 계열을 사용합니다. 두 클라이언트의 화면 흐름은 비슷하지만 인식 가능한 프로토콜 확장과 고급 매개변수는 완전히 같지 않습니다.

클라이언트 자체가 사용 가능한 노드를 자동으로 생성하지는 않습니다. 설치 후에도 유효한 구독 주소, 단일 노드 공유 링크를 가져오거나 서버 매개변수를 직접 입력해야 합니다. 구독 주소는 보통 여러 노드를 반환해 일괄 업데이트할 수 있으며, vmess:// 또는 vless://로 시작하는 공유 링크는 대개 하나의 노드만 나타냅니다. 두 유형을 같은 곳에 입력하지 마세요. 구독 주소는 “구독 그룹” 또는 “구독 설정”에 추가하고, 단일 노드 링크는 클립보드 가져오기, QR 코드 스캔 또는 수동 추가로 등록해야 합니다. 자세한 차이는 공유 링크와 구독 주소 안내에서 확인할 수 있습니다.

프로세서 아키텍처와 설치 패키지 유형 확인

다운로드하기 전에 기기의 아키텍처를 확인하세요. Windows와 대부분의 Linux 데스크톱 컴퓨터는 일반적으로 x64를 사용하며, Apple 칩을 탑재한 Mac은 arm64, 구형 Intel Mac은 x64를 사용합니다. 최근 주류 Android 기기는 대체로 arm64입니다. 아키텍처를 잘못 선택하면 설치 프로그램이 실행을 거부하거나, 시스템에서 앱이 호환되지 않는다고 표시하거나, 실행 직후 프로그램이 종료될 수 있습니다. Android 아키텍처를 판단하기 어렵다면 범용 패키지를 선택할 수 있지만 보통 용량이 더 큽니다. 기기가 arm64임을 확인했다면 arm64 패키지를 직접 선택하는 편이 좋습니다.

플랫폼	권장 클라이언트	일반적인 아키텍처	설치 패키지 방향
Windows	v2rayN	x64	데스크톱 버전 또는 클래식 WPF 버전
macOS	v2rayN	arm64 / x64	해당 칩용 DMG
Linux	v2rayN	x64 / arm64	deb 또는 rpm
Android	v2rayNG	arm64 / 범용	해당 아키텍처용 설치 패키지

설정 범위 기록

설정을 시작하기 전에 구독 이름, 현재 선택한 노드, 프록시 모드, TUN 사용 여부를 기록하는 것이 좋습니다. 이후 인터넷에 연결되지 않을 때 문제가 구독 해석, 노드 연결, 시스템 프록시 또는 투명 프록시 계층 중 어디에서 발생했는지 판단할 수 있습니다. 처음 설치할 때는 라우팅, DNS, 포트와 커널 매개변수를 동시에 변경하지 마세요. 먼저 기본 설정으로 확인 가능한 연결을 한 번 완료한 뒤 라우팅 분할과 TUN을 하나씩 활성화하세요. 여러 변수를 한꺼번에 바꾸면 로그를 구체적인 원인과 연결하기 어렵습니다.

시스템 시간과 시간대가 올바른지도 확인하세요. 일부 프로토콜의 핸드셰이크는 시간 범위에 의존하므로 기기 시간이 크게 어긋나면 겉으로는 연결 시간 초과처럼 보일 수 있습니다. 그다음 로컬에서 다른 프록시 도구가 수신 포트를 사용하고 있는지 확인하세요. 일반적인 로컬 포트에는 SOCKS, HTTP 및 혼합 프록시 포트가 있지만 클라이언트마다 기본값이 다를 수 있으므로 실제 클라이언트 설정 화면을 기준으로 해야 합니다. 다른 기기의 포트 값을 그대로 사용하지 마세요. 브라우저나 개발 도구에서 프록시를 별도로 사용할 계획이라면 클라이언트에 표시된 현재 수신 주소와 포트를 기록하세요.

설정 저장 및 민감한 정보 이해

구독 주소와 노드 링크에는 접근 매개변수가 포함될 수 있으므로 계정 인증 정보처럼 취급해야 합니다. 전체 주소를 공개 로그, 스크린샷 또는 공개 게시물에 붙여 넣지 마세요. 문제 해결에는 보통 프로토콜 유형, 전송 방식, TLS 상태, 서버 포트와 오류 메시지만 있으면 되며 서버 주소, 사용자 식별자와 구독 매개변수는 가려도 됩니다. 기기를 바꿀 때는 기존 클라이언트 데이터 디렉터리를 통째로 복사하기보다 새 기기에서 구독을 다시 추가하세요. 플랫폼마다 경로, 권한과 시스템 프록시 상태가 호환되지 않을 수 있습니다.

준비 단계의 완료 기준은 “프로그램이 열렸다”가 아닙니다. 클라이언트와 플랫폼이 맞고, 구독 출처가 분명하며, 시스템 시간이 정상이고, 포트에 뚜렷한 충돌이 없으며, 시스템 프록시와 TUN 중 무엇을 사용할지 알고 있어야 합니다. 이 점검을 마친 뒤 해당 플랫폼 장으로 이동하면 설치는 완료됐지만 고장 위치를 알 수 없는 상황을 크게 줄일 수 있습니다.

02 / WINDOWS

Windows: v2rayN 설치, 시스템 프록시 및 TUN

데스크톱 버전과 클래식 WPF 버전 선택

Windows 플랫폼에서는 v2rayN을 우선 사용합니다. 다운로드 센터는 데스크톱 버전과 클래식 WPF 버전을 함께 제공합니다. 데스크톱 버전은 새로운 크로스 플랫폼 인터페이스를 사용하므로 새로 설치하거나 macOS, Linux와 조작 방식을 통일하고 싶은 사용자에게 적합합니다. 클래식 WPF 버전은 익숙한 Windows 화면 구성을 유지하므로 이전 버전의 메뉴 위치에 익숙하거나 전통적인 데스크톱 상호작용이 필요한 환경에 적합합니다. 두 버전 모두 구독 관리, 노드 선택, 시스템 프록시와 라우팅 설정을 수행할 수 있으므로 동시에 설치할 필요는 없습니다. 기존 설정을 사용 중이라면 먼저 구독을 내보내거나 기록한 뒤 사용할 버전을 설치하세요.

Windows 다운로드 페이지로 이동한 뒤 x64 설치 패키지를 선택하세요. 설치 전에 실행 중인 기존 클라이언트를 종료해 설정 파일이 잠기지 않도록 합니다. 설치 프로그램을 사용한다면 마법사에서 현재 사용자 또는 시스템이 허용하는 위치를 선택하세요. 직접 실행하는 배포 형식이라면 쓰기 권한이 있는 고정 디렉터리에 압축을 풀고 임시 디렉터리에 장기간 두지 마세요. 클라이언트는 구독, 로그와 로컬 설정을 저장해야 하므로 디렉터리가 읽기 전용이면 설정이 저장된 것처럼 보여도 재시작 후 사라질 수 있습니다.

첫 실행 및 구독 가져오기

처음 실행한 후 먼저 구독 설정을 열고 알아보기 쉬운 그룹 이름을 만든 다음 구독 주소를 붙여 넣어 업데이트하세요. 업데이트가 끝나면 노드 목록으로 돌아가 최소 하나의 설정이 해석되었는지 확인합니다. 목록이 비어 있어도 바로 시스템 프록시를 켜지 말고 구독 업데이트 결과를 먼저 확인하세요. 빈 응답, 만료된 주소, 네트워크 요청 실패와 호환되지 않는 구독 형식은 모두 “추가에는 성공했지만 노드가 없음”을 일으킬 수 있습니다. 단일 노드 공유 링크를 받았다면 전체 링크를 복사한 뒤 “클립보드에서 가져오기”와 같은 메뉴를 사용하고 구독 주소 입력란에는 넣지 마세요.

노드를 선택한 뒤 클라이언트의 연결 테스트를 실행하거나 실제 연결을 한 번 수립해 보세요. 테스트 결과는 대상과 핸드셰이크가 가능한지만 판단하며 모든 웹사이트가 해당 노드를 사용한다는 뜻은 아닙니다. 실제로 확인하려면 시스템 프록시를 켠 뒤 시스템 프록시를 사용하는 브라우저 페이지에 접속하세요. 이미 실행 중인 일부 앱은 프록시 상태를 캐시하므로 시스템 프록시를 바꿔도 기존 연결을 계속 사용할 수 있습니다. 이 경우 앱을 완전히 종료한 뒤 다시 실행하세요.

시스템 프록시 모드의 적용 범위

시스템 프록시는 Windows 프록시 설정을 따르는 앱에 주로 영향을 줍니다. “시스템 프록시 자동 설정” 또는 같은 의미의 모드를 선택하면 v2rayN이 시스템 프록시를 로컬 수신 포트로 지정합니다. 클라이언트를 종료하기 전에는 시스템 프록시를 먼저 복원해야 합니다. 그렇지 않으면 시스템이 로컬 포트를 계속 가리켜 클라이언트 종료 후 브라우저가 인터넷에 접속하지 못할 수 있습니다. 정상 종료 시에는 보통 자동으로 처리되지만 강제 종료, 비정상적인 시스템 종료 또는 권한 차단으로 설정이 남을 수 있습니다.

Windows의 네트워크 및 인터넷 프록시 설정에서 프록시 스위치를 확인할 수 있습니다. 수동 프록시가 여전히 127.0.0.1을 가리키는데 v2rayN이 중지되었다면 해당 스위치를 끈 뒤 직접 연결을 테스트하세요. 시스템 프록시는 모든 프로그램을 강제로 가로채지 않습니다. 일부 게임, 명령줄 프로그램, 가상 머신과 자체 네트워크 스택을 사용하는 소프트웨어는 이를 무시할 수 있습니다. 이런 경우 앱에서 HTTP 또는 SOCKS 프록시를 지정하거나 TUN 사용을 검토해야 합니다.

TUN 모드 및 권한

TUN은 가상 네트워크 인터페이스를 만들어 시스템 프록시를 읽지 않는 더 많은 트래픽이 클라이언트로 들어오게 합니다. 사용 시 보통 관리자 권한이 필요하며, 처음 인터페이스를 만들 때 시스템 확인 창이 표시될 수 있습니다. 먼저 가상 네트워크 카드를 만드는 다른 네트워크 도구를 종료한 뒤 일반적인 방식으로 v2rayN을 실행하고 TUN을 켜세요. 여러 투명 프록시 도구를 동시에 사용하면 라우팅 테이블과 DNS가 서로 덮어쓸 수 있습니다. TUN을 켠 후에는 일반 웹페이지를 먼저 테스트하고, 시스템 프록시를 따르지 않던 앱을 이어서 테스트하세요. 모든 네트워크가 동시에 끊기면 우선 TUN을 끄고 기본 네트워크를 복구하세요.

시작 시 실행, 로그 및 일반적인 차단

부팅 시 실행해야 한다면 v2rayN의 시작 시 실행 옵션을 켤 수 있지만 “프로그램 자동 시작”과 “시스템 프록시 자동 활성화”를 같은 항목으로 생각하지 마세요. 전자는 클라이언트 프로세스의 시작만 보장하고, 후자는 시작 후 시스템 프록시를 수정할지 결정합니다. 공용 컴퓨터나 네트워크를 자주 바꾸는 기기에서는 클라이언트만 시작한 뒤 노드를 확인하고 프록시를 수동으로 켜는 편이 적합합니다. 노트북이 절전 모드에서 복귀한 뒤 노드가 작동하지 않으면 바로 클라이언트를 재설치하지 말고 노드를 한 번 전환하거나 커널을 재시작해 보세요.

시작 실패 또는 갑작스러운 종료가 발생하면 먼저 설치 디렉터리에 쓰기 권한이 있는지, 기존 프로세스가 종료되었는지, 로컬 포트가 사용 중인지 확인한 뒤 시스템 실행 환경과 보안 정책을 점검하세요. 로그에 “address already in use”가 표시되면 보통 수신 포트 충돌을 의미합니다. 설정 해석 오류가 표시되면 최근 가져온 노드나 사용자 지정 라우팅을 확인하세요. 첫 단계로 모든 설정을 삭제하지 말고 설정 디렉터리를 백업한 다음 최근 추가된 설정을 다른 곳으로 옮기고 재시작하세요. 더 자세한 시작 오류 분기는 클라이언트가 열리지 않거나 갑자기 종료될 때의 문제 해결에서 확인할 수 있습니다.

Windows 장의 완료 기준은 구독 업데이트, 노드 선택, 시스템 프록시를 켠 뒤 브라우저가 예상한 경로를 사용하는 것, 시스템 프록시를 끈 뒤 직접 연결이 복구되는 것입니다. 시스템 프록시를 따르지 않는 프로그램까지 적용해야 할 때만 TUN을 추가로 활성화하세요. 조정할 때마다 관련 로그를 일정 구간 보관하면 노드 불가, 프록시 잔류, 포트 충돌과 가상 네트워크 카드 문제를 구분하는 데 도움이 됩니다.

03 / MACOS

macOS: 칩 선택, 권한 허용 및 프록시 가로채기

칩 확인 및 v2rayN 설치

macOS에서는 v2rayN 데스크톱 버전을 사용합니다. 다운로드 전에 시스템 정보 또는 “이 Mac에 관하여”를 열고 프로세서나 칩 항목을 확인하세요. Apple 칩으로 표시되면 arm64 DMG를, Intel 프로세서로 표시되면 x64 DMG를 선택합니다. 설치 패키지 아키텍처가 칩과 맞지 않으면 열리지 않거나 호환 변환 계층에 의존해 실행되어 문제 해결 변수가 늘어날 수 있습니다. macOS 다운로드 페이지에서 칩에 맞는 파일을 선택하고 DMG를 연 다음 앱을 “응용 프로그램” 폴더로 이동하세요.

처음 실행할 때 시스템이 차단하더라도 계속 두 번 클릭하지 마세요. 먼저 “개인정보 보호 및 보안” 설정에서 최근 차단된 앱 기록을 확인하고, 이름이 방금 설치한 v2rayN과 일치하는지 확인한 뒤 열기를 허용하세요. “응용 프로그램”에서 앱을 마우스 오른쪽 버튼으로 열어 시스템에 명확한 확인 창을 한 번 표시하게 할 수도 있습니다. 허용을 마치면 이후에는 런치패드나 응용 프로그램 폴더에서 정상적으로 시작할 수 있습니다. 세부 메뉴 경로는 시스템 소버전에 따라 달라질 수 있으므로 macOS 첫 실행 및 네트워크 권한 처리를 참고하세요.

구독 가져오기 및 메뉴 막대 상태

클라이언트를 실행한 뒤 먼저 주 창 또는 메뉴 막대 아이콘이 나타났는지 확인하세요. 구독을 추가할 때 그룹을 만들고 주소를 붙여 넣어 저장한 뒤 업데이트하고, 노드 목록에서 설정 하나를 선택합니다. 주소를 복사한 뒤 붙여 넣을 수 없다면 클립보드 내용에 앞뒤 공백, 줄 바꿈 또는 메신저가 추가한 설명이 포함되지 않았는지 확인하세요. 구독 주소는 하나의 연속된 문자열이어야 합니다. 단일 노드 링크는 클립보드 가져오기 메뉴를 사용하고, 가져온 뒤 프로토콜, 포트, 전송 방식과 TLS 등의 항목이 완전한지 확인하세요.

macOS에서는 앱 창을 닫았다고 프로세스가 종료되는 것은 아닙니다. 창 닫기 버튼을 눌러도 v2rayN이 메뉴 막대에 남아 프록시를 계속 유지할 수 있습니다. 문제를 해결하거나 재시작할 때는 메뉴 막대에서 종료한 뒤 활성 상태 보기에서 관련 프로세스가 끝났는지 확인하세요. 창만 닫은 채 다른 앱을 설치하면 두 인스턴스가 로컬 포트를 동시에 사용하려 할 수 있습니다.

시스템 프록시 및 네트워크 서비스

시스템 프록시를 켜면 클라이언트가 현재 네트워크 서비스의 프록시 설정을 조정합니다. macOS에는 Wi-Fi, 유선 네트워크 카드와 기타 네트워크 서비스가 동시에 존재할 수 있으므로 네트워크를 전환할 때 현재 활성 서비스에 프록시가 적용되었는지 확인하세요. Wi-Fi에서는 정상인데 유선 네트워크에 연결한 뒤 작동하지 않는다면 먼저 시스템 프록시를 한 번 껐다 켜고 노드 문제로 단정하지 마세요. 브라우저와 대부분의 데스크톱 앱은 시스템 프록시를 읽지만 명령줄 도구가 설정을 따르는지는 도구 자체에 따라 다릅니다. 필요하면 현재 터미널 세션에서 프록시 환경 변수를 설정하세요.

export HTTP_PROXY="http://127.0.0.1:로컬HTTP포트"
export HTTPS_PROXY="http://127.0.0.1:로컬HTTP포트"
export ALL_PROXY="socks5://127.0.0.1:로컬SOCKS포트"

# 현재 터미널 직접 연결 복원
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY

위 예시의 포트는 v2rayN 설정 화면에 실제로 표시된 수신 포트로 바꿔야 합니다. 환경 변수는 현재 터미널에서 시작되고 해당 변수를 읽는 프로그램에만 영향을 주며 시스템 프록시를 대신하거나 다른 터미널 창을 자동으로 덮어쓰지 않습니다. 명령줄 접속을 점검할 때는 먼저 env를 실행해 이전 프록시 변수가 남아 있는지 확인하세요. 클라이언트 포트는 바뀌었지만 터미널은 여전히 이전 포트를 가리키는 것이 “브라우저는 정상인데 명령줄은 실패하는” 흔한 원인입니다.

TUN, 네트워크 확장 및 권한 승인

TUN을 사용할 때 시스템에서 로컬 관리자 인증 정보를 입력하거나 네트워크 확장 추가를 확인하도록 요구할 수 있습니다. 권한 승인은 시스템 팝업과 설정 화면에서 진행하세요. 승인을 거부해도 클라이언트의 시스템 프록시는 정상 작동할 수 있지만 TUN은 만들 수 없습니다. 활성화 후에는 시스템 네트워크 설정에서 새 네트워크 인터페이스 또는 관련 상태를 확인할 수 있습니다. 이때 인터페이스를 직접 삭제하지 말고 v2rayN에서 TUN을 끄고 클라이언트를 종료한 뒤 남은 항목을 처리하세요.

회사 네트워크, 게스트 Wi-Fi와 웹 인증이 필요한 핫스팟에서는 먼저 네트워크 로그인을 완료한 뒤 TUN을 켜세요. 그렇지 않으면 인증 페이지가 프록시나 DNS 가로채기로 차단될 수 있습니다. 네트워크를 바꾼 뒤 연결됨으로 표시되지만 데이터가 오가지 않으면 “TUN 끄기—직접 연결 복구 확인—구독 다시 업데이트—다시 활성화” 순서로 처리하세요. 기본 네트워크가 아직 연결되지 않은 상태에서 노드를 반복해서 바꾸는 일을 피할 수 있습니다.

절전 모드 복귀 및 프록시 잔류

Mac이 절전 모드에서 복귀하거나 Wi-Fi를 이동하거나 핫스팟을 전환하면 기존 연결이 끊겼을 수 있습니다. 먼저 클라이언트 로그에서 아웃바운드 연결이 다시 수립되는지 확인한 다음 접속을 테스트하세요. 시스템 프록시는 켜져 있지만 로컬 커널이 복구되지 않으면 앱이 계속 수신하지 않는 포트로 트래픽을 보냅니다. 시스템 프록시를 먼저 끄고 직접 연결이 정상인지 확인한 뒤 클라이언트를 재시작하고 다시 켜세요. 강제 종료 후 전체 네트워크가 작동하지 않는다면 현재 네트워크 서비스의 프록시 세부 설정에서 HTTP, HTTPS와 SOCKS 항목이 여전히 선택되어 있는지도 확인하세요.

로그인 후 자동 실행이 필요하다면 클라이언트의 시작 옵션이나 시스템 로그인 항목을 사용할 수 있지만 중복 등록은 피해야 합니다. 시스템 로그인 항목과 클라이언트 내부 자동 시작을 동시에 설정하면 짧은 시간에 두 프로세스가 실행될 수 있습니다. 안정적인 설정은 하나의 시작 경로만 남기고 시스템 프록시를 자동으로 수정할지 명확히 정하는 것입니다. macOS 장의 확인 순서는 시스템 권한 확인 통과, 구독 업데이트 성공, 메뉴 막대 상태 확인, 시스템 프록시 켜기·끄기, 네트워크 전환 후 복구입니다. TUN은 독립적인 계층으로 검증하며 최초 설치와 동시에 처리하지 않습니다.

04 / LINUX

Linux: deb, rpm, 데스크톱 프록시 및 자동 시작

배포판 패키지 형식 선택

Linux 데스크톱에서는 v2rayN을 사용합니다. Debian, Ubuntu 및 일반적인 파생 시스템은 deb를 선택하고, Fedora, Rocky Linux, openSUSE 등 rpm 패키지 관리 체계를 사용하는 환경은 rpm을 선택합니다. 일반적인 데스크톱 x64 프로세서는 x64 패키지를, arm64 기기는 해당 arm64 패키지를 사용하세요. 패키지 형식과 아키텍처가 모두 맞아야 하며 데스크톱 환경 이름만으로 패키지 유형을 판단할 수는 없습니다. 터미널에서 다음 명령을 실행해 아키텍처와 배포판 정보를 확인할 수 있습니다.

uname -m
cat /etc/os-release

x86_64는 보통 x64, aarch64는 보통 arm64에 해당합니다. 배포판 정보의 ID와 ID_LIKE는 패키지 관리 체계를 판단하는 데 도움이 됩니다. Linux 다운로드 페이지에서 해당 파일을 선택하세요. 소프트웨어 패키지를 압축 파일처럼 직접 풀어 실행하지 말고 시스템 패키지 관리자로 설치하세요. 데스크톱 실행 항목, 의존성 및 제거 정보가 함께 등록됩니다.

deb 또는 rpm 설치

터미널에서 다운로드 디렉터리로 이동한 뒤 시스템 패키지 관리자를 사용해 설치할 수 있습니다. 파일 이름은 현재 다운로드한 내용에 따라 달라집니다. 명령을 입력할 때 앞부분 몇 글자만 입력하고 Tab 키로 자동 완성하면 직접 입력할 때의 오타를 피할 수 있습니다. 다음 명령의 파일 이름은 현재 디렉터리에 이미 다운로드한 패키지를 뜻합니다.

# Debian / Ubuntu 계열
sudo apt install ./v2rayN-downloaded-package.deb

# Fedora 계열
sudo dnf install ./v2rayN-downloaded-package.rpm

apt install ./파일.deb 또는 dnf install ./파일.rpm을 사용하면 하위 수준의 압축 해제 명령보다 의존성을 처리하기 쉽습니다. 설치가 끝나면 데스크톱 앱 목록에서 v2rayN을 실행하세요. 실행 항목을 찾을 수 없다면 먼저 터미널에 앱 실행 명령을 입력해 누락된 라이브러리, 디스플레이 서비스 또는 권한 오류가 있는지 확인한 뒤 데스크톱 앱 데이터베이스를 새로 고치세요. 의존성 하나를 해결하려고 출처가 불명확한 런타임을 무더기로 설치하지 말고 패키지 관리자가 제시한 정확한 패키지 이름을 기준으로 처리하세요.

데스크톱 프록시 및 환경 변수

GNOME, KDE 등의 데스크톱 환경에는 네트워크 프록시 설정이 있지만 위치와 자동 적용 범위는 서로 다릅니다. v2rayN의 시스템 프록시 기능은 데스크톱 프록시 설정과 최대한 연동하므로, 확인할 때 먼저 데스크톱 시스템 설정에서 프록시 모드가 변경되었는지 확인한 뒤 브라우저로 테스트하세요. 터미널에서 HTTP_PROXY만 내보낸다고 데스크톱 전체에 프록시가 켜지는 것은 아닙니다. 반대로 데스크톱 프록시가 활성화되어도 모든 명령줄 도구가 이를 읽는다는 보장은 없습니다.

# 현재 shell 세션에만 설정
export http_proxy="http://127.0.0.1:로컬HTTP포트"
export https_proxy="http://127.0.0.1:로컬HTTP포트"
export all_proxy="socks5://127.0.0.1:로컬SOCKS포트"

# 현재 세션 정리
unset http_proxy https_proxy all_proxy

로컬 수신이 기본적으로 루프백 주소에만 바인딩되어 있으면 본기기의 프로그램만 연결할 수 있습니다. 같은 LAN의 다른 기기에서 이 포트를 사용하게 하려면 LAN 연결을 명시적으로 허용하고 수신 주소와 방화벽을 조정해야 합니다. 이는 서비스 노출 범위를 넓히므로 최초 설치에 필요한 단계가 아닙니다. 명확한 요구가 없다면 루프백 수신을 유지하세요.

TUN, 권한 부여 및 라우팅

Linux에서 TUN을 사용하려면 시스템에 /dev/net/tun이 제공되어야 하며 인터페이스 생성, 라우팅 변경과 DNS 처리를 위한 권한도 필요합니다. 데스크톱 클라이언트는 권한 대화 상자로 권한을 요청하거나 이미 설치된 권한 관리 구성 요소에 의존할 수 있습니다. 활성화에 실패하면 먼저 TUN 장치가 존재하는지 확인하고, 로그에서 “permission denied”, “operation not permitted” 또는 라우트 추가 실패 메시지를 확인하세요. 그래픽 클라이언트 전체를 장기간 root로 실행하지 마세요. 사용자 디렉터리의 설정 파일 소유자가 바뀌어 이후 일반 사용자가 설정을 저장하지 못할 수 있습니다.

가상 머신, 컨테이너 데스크톱과 제한된 기업 환경에서는 TUN이 비활성화될 수 있습니다. 이때도 시스템 프록시는 사용할 수 있으므로 작동하는 시스템 프록시 방식을 먼저 유지하세요. TUN을 켠 뒤 도메인 접속만 실패하고 직접 주소 연결은 정상이라면 DNS를 중점적으로 확인하세요. 모든 트래픽이 즉시 끊기면 기본 라우트, 정책 라우팅과 다른 가상 네트워크 소프트웨어의 충돌을 확인합니다. TUN을 끈 뒤 가상 인터페이스와 추가 라우트가 정리되었는지 확인하고 다음 테스트를 진행하세요.

로그인 시 자동 시작 및 데스크톱 세션

그래픽 클라이언트는 사용자 데스크톱 세션이 만들어진 뒤 시작되어야 합니다. 우선 v2rayN 내장 자동 시작 설정을 사용하세요. 데스크톱 환경이 제대로 처리하지 못하면 사용자 수준 systemd 서비스를 사용할 수 있지만, 서비스는 그래픽 세션과 네트워크가 준비될 때까지 기다리고 현재 사용자 권한으로 실행되어야 합니다. 전체 과정은 Linux 설치 및 부팅 시 자동 시작 설정에서 확인할 수 있습니다. 자동 시작을 설정한 뒤 실제로 로그아웃했다가 다시 로그인해 테스트하세요. 서비스 명령을 한 번 실행한 것만으로 성공했다고 판단하지 마세요.

자동 시작에 실패하면 시스템 서비스 목록이 아니라 사용자 수준 로그를 확인하세요. 흔한 원인은 업데이트 후 프로그램 경로 변경, 사용할 수 없는 디스플레이 환경 변수, 아직 잠기지 않은 데스크톱 키링, 네트워크 주소 미할당입니다. 이동이 잦은 기기에서는 클라이언트만 자동으로 시작하고 TUN은 즉시 강제 활성화하지 않는 것이 좋습니다. 네트워크 인증과 데스크톱 세션이 먼저 완료된 뒤 사용자가 현재 네트워크 환경을 확인하세요.

제거, 업그레이드 및 설정 보존

업그레이드할 때는 현재 배포판과 아키텍처에 맞는 새 패키지를 덮어 설치하면 됩니다. 설치 전에 클라이언트를 정상 종료해 커널 프로세스와 설정 파일이 사용 중이지 않게 하세요. 패키지 관리자로 제거해도 사용자 홈 디렉터리의 모든 설정이 자동으로 삭제되지는 않으므로 재설치 후 기존 구독이 다시 나타날 수 있습니다. 새 설정으로 문제를 확인하려면 먼저 사용자 설정 디렉터리를 백업한 뒤 기존 디렉터리의 이름을 바꾸세요. 직접 삭제하지 않으면 구독과 라우팅 규칙을 언제든 복구할 수 있습니다.

Linux 장의 완료 기준은 시스템 패키지 관리자가 v2rayN을 인식하고, 데스크톱 실행 항목이 시작되며, 구독과 노드가 현재 사용자 디렉터리에 저장되고, 데스크톱 프록시를 끈 뒤 직접 연결이 복구되며, TUN을 끈 뒤 라우팅 테이블이 정상인 것입니다. 문제가 터미널 도구에서만 발생하면 환경 변수를 우선 확인하고, 그래픽 앱에서만 발생하면 데스크톱 프록시를 확인하세요. 시스템 전체에 영향을 주면 TUN, DNS와 라우팅을 점검합니다.

05 / ANDROID

Android: v2rayNG, v2flyNG 및 시스템 VPN 가로채기

클라이언트 및 아키텍처 선택

Android에서는 v2rayNG을 우선 사용하며 V2Fly 커널 계열이 필요할 때는 v2flyNG를 선택할 수 있습니다. 두 클라이언트 모두 arm64와 범용 패키지를 제공합니다. 2015년 이후의 주류 스마트폰은 보통 arm64이지만 기기 정보를 기준으로 판단해야 합니다. arm64임을 확인했다면 arm64 패키지를, 확인하기 어렵다면 범용 패키지를 선택하세요. 두 클라이언트를 동시에 연결 상태로 유지하지 마세요. 시스템에서는 보통 이런 VPN 세션 하나만 동시에 활성 상태로 둘 수 있습니다.

Android 다운로드 페이지에서 설치 패키지를 받은 뒤 시스템에서 현재 브라우저 또는 파일 관리자가 앱을 설치하도록 허용해야 할 수 있습니다. 설치 패키지를 실제로 여는 앱에만 권한을 부여하세요. 설치가 끝나면 이 출처의 설치 권한을 끌 수 있습니다. 설치할 수 없다는 메시지가 표시되면 먼저 동일한 이름의 앱이 다른 서명 출처에서 설치되어 있는지, 저장 공간이 충분한지, 다운로드 파일이 기기에 완전히 저장되었는지 확인하세요. 오류 정보를 덮어쓰지 않도록 설치 버튼을 반복해서 누르지 마세요.

구독 및 단일 노드 링크 가져오기

v2rayNG 또는 v2flyNG을 연 뒤 구독 주소를 구독 그룹에 추가하고 업데이트하세요. 업데이트가 끝나면 설정 목록에서 노드를 선택합니다. 단일 노드 공유 링크는 클립보드에 복사한 뒤 클립보드 가져오기 기능을 사용하고, QR 코드는 클라이언트의 스캔 메뉴에서 가져오며 시스템이 요구하면 카메라 권한을 허용하세요. 가져온 뒤 목록에 중복 항목이 나타나면 클립보드 가져오기를 여러 번 실행했거나 같은 구독을 여러 그룹에 추가했을 가능성이 큽니다. 출처가 분명한 하나만 남기세요.

모바일 기기의 클립보드는 긴 링크를 복사할 때 일부를 잘라낼 수 있습니다. 가져오기에 실패하면 먼저 내용을 로컬 텍스트 편집기에 붙여 넣고 시작 프로토콜, 끝의 매개변수와 중간 문자열이 끊기지 않았는지 확인하세요. 인코딩된 공유 링크를 메신저 창에서 직접 수정하지 마세요. 문자 하나만 바뀌어도 해석에 실패할 수 있습니다. 구독을 업데이트했는데 노드가 바뀌지 않으면 현재 보고 있는 목록이 해당 구독 그룹인지 먼저 확인한 뒤 업데이트 안내를 확인하세요. 서버의 내용이 바뀌지 않은 것을 클라이언트 오류로 오해하지 않도록 합니다.

첫 연결 및 시스템 확인

노드를 선택하고 연결을 누르면 Android에 VPN 연결 생성에 대한 시스템 확인 창이 표시됩니다. 이 확인을 완료해야 상태 표시줄에 연결 아이콘이 나타납니다. 클라이언트 화면에서 노드가 선택된 상태라고 해서 시스템 트래픽이 이미 프록시로 들어간다는 뜻은 아닙니다. 처음 확인할 때는 기본 라우팅과 DNS를 유지하고 연결 후 브라우저로 테스트하세요. 브라우저가 정상 작동하면 다른 앱을 테스트합니다. 연결 아이콘은 보이지만 모든 앱이 접속하지 못한다면 먼저 연결을 끊고 모바일 데이터나 Wi-Fi 자체가 정상인지 확인하세요.

Wi-Fi에서 모바일 네트워크로 전환하면 기존 연결을 다시 수립해야 할 수 있습니다. 시스템 절전 정책이 화면 잠금 후 백그라운드 프로세스를 제한하면 연결 아이콘은 남아 있지만 커널이 데이터 전송을 중지할 수 있습니다. 시스템 배터리 설정에서 클라이언트가 필요한 백그라운드 실행을 하도록 허용하고, 원클릭 정리 도구로 프로세스를 강제 종료하지 마세요. 제조사마다 설정 이름은 다르지만 핵심은 연결 중 클라이언트가 포그라운드 서비스와 네트워크 활동을 유지하도록 허용하는 것입니다.

앱별 프록시 및 우회 규칙

Android 클라이언트는 보통 앱별 프록시를 제공합니다. 지정한 앱만 프록시에 연결하거나 선택한 앱을 프록시에서 우회하도록 설정할 수 있습니다. 두 모드는 방향이 반대이므로 설정 전에 현재 모드를 확인하세요. 처음에는 전체 앱에 적용한 상태로 기본 연결을 확인한 다음 선별하는 것이 좋습니다. “선택한 앱만 프록시”를 켜고 브라우저 선택을 잊으면 테스트에서 노드가 전혀 작동하지 않는 것처럼 보입니다. “선택한 앱 우회”를 사용하면 선택한 앱은 직접 연결됩니다.

시스템 구성 요소, 다운로드 관리자와 앱 내 웹페이지는 서로 다른 프로세스에서 요청을 보낼 수 있습니다. 주 앱만 선택해도 호출되는 모든 시스템 서비스가 포함되는 것은 아닙니다. 로그인 페이지는 열리지만 다운로드가 실패한다면 앱별 제한을 잠시 끄고 비교하세요. 문제가 앱 필터에서 비롯된 것을 확인한 뒤 관련 구성 요소를 하나씩 추가하고, 곧바로 노드 프로토콜이나 DNS를 바꾸지는 마세요.

필요 시 연결, 항상 연결 및 LAN 접근

시스템 설정의 항상 켜짐 VPN은 네트워크가 복구된 뒤 클라이언트 연결을 유지하려고 시도하므로 안정적인 설정으로 같은 클라이언트를 장기간 사용하는 기기에 적합합니다. “VPN을 통과하지 않는 연결 차단”을 켜면 가로채기 범위가 넓어지지만 노드를 사용할 수 없거나 클라이언트가 시작되지 않을 때 기기가 인터넷에 전혀 연결되지 않을 수 있습니다. 최초 설치 단계에서는 두 옵션을 동시에 켜지 말고 구독 업데이트, 노드 전환과 연결 해제 후 복구가 정상인지 먼저 확인하세요.

프린터, 화면 공유 기기, 라우터 관리 페이지 또는 기타 LAN 서비스에 접근하려면 LAN 우회 규칙을 활성화해야 할 수 있습니다. 대표적인 사설 주소는 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16입니다. 프록시를 켠 뒤 인터넷에는 접속되지만 LAN 기기를 찾지 못한다면 라우팅이 사설 주소까지 원격 아웃바운드로 보내는지 확인하세요. 실제 LAN 범위를 기준으로 하지 않고 알 수 없는 주소 대역 전체를 임의로 직접 연결로 설정하지 마세요.

로그, 배터리 소모 및 백그라운드 문제

모바일에서 문제를 해결할 때는 먼저 클라이언트 로그의 시간이 방금 수행한 작업과 일치하는지 확인하세요. 연결 시간 초과, DNS 해석 실패, 설정 해석 실패와 시스템의 서비스 강제 중지는 서로 다른 원인입니다. 백그라운드에서 돌아온 직후 앱이 연결을 끊으면 배터리 최적화를 중점적으로 확인하세요. 노드를 바꿨는데도 이전 노드로 표시되면 먼저 연결을 끊었다가 다시 연결하세요. 특정 앱만 실패한다면 앱별 설정과 해당 앱이 사설 DNS 또는 특수 네트워크 스택을 사용하는지 확인하세요.

지속적인 연결은 포그라운드 서비스를 유지하며 정상적인 네트워크와 배터리 소모를 발생시킵니다. 배터리가 비정상적으로 빨리 줄면 노드의 반복 재연결, 약한 신호로 인한 네트워크 전환과 지나치게 높은 로그 수준을 먼저 배제하세요. 로그를 장기간 가장 상세한 수준으로 유지하지 말고 문제 해결 후 일반 수준으로 되돌리세요. Android 장의 완료 기준은 시스템 연결 확인 통과, 브라우저 검증, 연결 해제 후 직접 연결 복구, 네트워크 전환 후 재연결 가능 여부, 앱별 규칙과 백그라운드 정책이 실제 사용 범위에 맞는지입니다.

06 / SUBSCRIPTION AND ROUTING

구독 관리, 노드 선택 및 라우팅 분할

구독 업데이트의 전체 과정

구독 업데이트는 단순히 “목록 하나를 다운로드하는” 작업이 아닙니다. 클라이언트가 먼저 구독 주소를 요청하고, 응답을 읽은 뒤 지원되는 형식으로 노드를 해석하고, 마지막으로 지정된 그룹에 기록합니다. 요청 단계는 네트워크나 주소 상태의 영향을 받고, 해석 단계는 형식과 커널 기능의 영향을 받으며, 기록 단계는 설정 디렉터리 권한이나 그룹 설정의 영향을 받을 수 있습니다. 업데이트 후에는 안내 메시지, 그룹 이름과 노드 수의 변화를 함께 확인하세요. 버튼이 눌렸는지만 보지 마세요.

같은 구독을 여러 그룹에 중복 추가하지 마세요. 중복 구독은 이름이 비슷한 노드를 만들어 현재 선택한 항목이 어느 업데이트에서 온 것인지 판단하기 어렵게 합니다. 용도나 출처에 따라 안정적인 그룹을 만들고 이름에 버전과 날짜를 기록할 필요는 없습니다. 업데이트 시각은 클라이언트 상태나 로그로 확인할 수 있습니다. 구독을 삭제하기 전에 “이 구독의 노드도 함께 삭제”가 선택되어 있는지 확인해 출처를 잃은 이전 설정이 남거나 사라지는 일을 피하세요. 구독 주소가 바뀌면 임시 그룹을 여러 개 만들기보다 기존 그룹을 편집해 업데이트하세요.

노드 매개변수 및 호환 범위

노드를 가져올 수 있는지는 클라이언트와 커널이 해당 프로토콜, 전송 계층 및 추가 매개변수를 인식하는지에 따라 달라집니다. VMess, VLESS 등의 프로토콜은 연결의 일부만 설명하며 실제 설정에는 TCP, WebSocket, gRPC, TLS, REALITY, 서비스 이름, 경로와 서버 이름 등이 포함될 수 있습니다. 가져오기는 성공했지만 연결에 실패한다면 복사나 구독 변환 과정에서 핵심 필드가 누락되지 않았는지 확인하세요. 클라이언트 간에 이전할 때는 특정 클라이언트가 생성한 내부 설정 파일을 다른 플랫폼에 직접 넘기지 말고 원본 구독을 다시 가져오는 편이 좋습니다.

노드 이름은 식별을 위한 레이블일 뿐 실제 회선 품질을 의미하지 않습니다. 테스트할 때는 노드 하나를 선택해 실제 연결을 수립하고 로그와 함께 판단하세요. 한 번의 지연 시간 테스트 실패는 대상이 탐색에 응답하지 않았거나 현재 네트워크가 패킷을 잃었거나 프로토콜 핸드셰이크가 완료되지 않았기 때문일 수 있습니다. 반대로 한 번 낮은 지연 시간이 표시되어도 지속적인 전송 안정성을 보장하지 않습니다. 문제 해결의 목표는 특정 숫자를 얻는 것이 아니라 “연결 수립 가능 여부, 도메인 해석 완료 여부, 요청이 올바른 아웃바운드로 들어갔는지”를 확인하는 것입니다.

라우팅 규칙의 매칭 방식

라우팅 규칙은 보통 도메인, 주소, 포트, 네트워크 유형 또는 프로세스 정보를 기준으로 매칭한 뒤 트래픽을 프록시, 직접 연결 또는 차단 아웃바운드로 보냅니다. 규칙 순서는 중요합니다. 더 구체적인 조건을 일반 규칙보다 앞에 두고 마지막에 기본 아웃바운드를 설정하세요. 광범위한 규칙이 먼저 매칭되면 뒤의 정밀한 규칙은 적용되지 않습니다. 수정 전에 현재 라우팅 모드를 기록하고, 완료 후 직접 연결되어야 하는 대상과 프록시를 사용해야 하는 대상을 각각 테스트해 양쪽이 예상대로 작동하는지 확인하세요.

도메인 규칙과 주소 규칙은 서로 다른 단계에서 작동합니다. 앱이 먼저 도메인을 요청하고 DNS가 주소를 반환하면 커널이 해석 결과에 따라 주소 규칙을 추가로 적용할 수 있습니다. 도메인 스니핑을 활성화하면 커널이 트래픽에서 대상 도메인을 복원해 추가 라우팅 분할에 사용할 수도 있습니다. 스니핑은 많을수록 좋은 기능이 아닙니다. 일부 비표준 프로토콜, 암호화 연결 또는 LAN 서비스에는 적합하지 않을 수 있습니다. 처음에는 클라이언트 기본값을 유지하고 명확한 문제가 있을 때만 조정하세요.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "domain:example.com"
        ],
        "outboundTag": "proxy"
      }
    ]
  }
}

위 예시는 규칙 구조를 보여 줍니다. 사설 주소는 직접 연결 아웃바운드로, 지정한 예시 도메인은 프록시 아웃바운드로 보냅니다. 실제 사용 시 outboundTag는 현재 설정에 존재하는 아웃바운드 태그와 일치해야 합니다. 클라이언트가 다른 태그 이름을 사용한다면 그대로 복사할 경우 규칙이 대상 아웃바운드를 찾지 못합니다. 그래픽 클라이언트는 보통 사전 설정된 라우팅 화면을 제공하므로 먼저 화면에서 수정하고, 생성 결과를 명확히 이해할 때만 하위 JSON을 편집하세요.

시스템 프록시, PAC 및 전역 라우팅

시스템 프록시는 시스템 설정을 따르는 앱을 로컬 포트로 보내고, 라우팅 규칙은 트래픽이 커널에 들어온 뒤 어느 아웃바운드로 갈지 결정합니다. 이 두 계층을 혼동하지 마세요. 앱이 로컬 프록시에 들어오지 않으면 커널 라우팅을 아무리 완벽하게 작성해도 적용되지 않습니다. 반대로 앱이 프록시에 들어왔지만 규칙에 따라 직접 연결로 보내지면 “클라이언트는 켜졌지만 대상은 여전히 직접 연결”되는 것처럼 보입니다. PAC 또는 자동 설정 스크립트는 시스템 프록시 계층에서 먼저 대상을 선택하므로 문제 해결 시 PAC가 선택하지 않은 것인지 커널 라우팅이 직접 연결을 선택한 것인지 확인해야 합니다.

간단하고 안정적인 구성이 필요하다면 시스템 프록시로 브라우저 트래픽을 클라이언트에 통합하고, 커널 라우팅으로 직접 연결과 프록시를 결정하게 하세요. 더 많은 앱을 가로채야 할 때 TUN을 사용하면 됩니다. 여러 출처의 PAC, 사용자 지정 브라우저 프록시 확장과 시스템 프록시를 동시에 활성화하지 마세요. 여러 계층의 결정이 생겨 같은 도메인도 앱마다 다른 경로를 사용할 수 있습니다. 단일 진입점을 유지해야 로그가 요청을 정확히 보여 줍니다.

구독 업데이트 후 안전한 변경 절차

구독을 업데이트하면 기존 노드가 삭제되거나 새 노드가 추가되고 이름이 바뀔 수 있습니다. 업데이트 전에 사용하던 노드가 제거되면 클라이언트가 다른 설정으로 전환하거나 만료된 참조를 유지할 수 있습니다. 업데이트 후 현재 선택한 항목이 여전히 존재하는지 확인하고 다시 연결하세요. 사용자 지정 라우팅이 특정 아웃바운드를 노드 태그로 가리킨다면 업데이트로 태그가 바뀌었는지도 확인해야 합니다. 그룹에 노드가 많을수록 표시 이름에 의존하기보다 명확한 구독 그룹과 고정된 라우팅 아웃바운드를 사용하는 편이 안정적입니다.

권장 변경 순서는 현재 노드와 라우팅 모드 기록, 구독 업데이트, 해석 결과 확인, 노드 선택, 기본 라우팅에서 먼저 테스트, 사용자 지정 규칙 복원입니다. 업데이트 직후 실패하면 업데이트 전에도 남아 있는 노드로 전환해 비교하세요. 구독과 라우팅 문제는 용어집에서 프로토콜, 아웃바운드, 라우팅 분할과 DNS 개념을 확인할 수도 있습니다. 화면 레이블을 같은 설정 계층으로 오해하지 않도록 하세요.

07 / TUN AND DNS

TUN, DNS 및 시스템 네트워크 경계

TUN이 필요한 경우

TUN은 가상 네트워크 인터페이스로 시스템 트래픽을 받아 시스템 프록시를 읽지 않는 프로그램까지 적용하는 기능입니다. 브라우저와 일반 데스크톱 앱이 시스템 프록시로 정상 작동한다면 “설정을 더 완벽하게 만들기 위해” TUN을 강제로 켤 필요는 없습니다. 게임 런처, 일부 명령줄 도구, 독립 네트워크 스택 앱 또는 통합 가로채기가 필요한 상황이 TUN을 검토할 주요 이유입니다. TUN은 라우팅, DNS, 권한과 가상 인터페이스라는 네 가지 변수를 추가하므로 적용 범위가 넓은 만큼 문제 해결 과정도 길어집니다.

활성화하기 전에 기본 라우트를 변경하거나 가상 네트워크 카드를 만드는 다른 도구를 끄고 시스템 프록시 상태를 기록하세요. 대부분의 경우 TUN과 시스템 프록시가 같은 트래픽을 중복해서 처리할 필요는 없으며, 동시에 켤 수 있는지는 클라이언트 구현에 따라 다릅니다. 확실하지 않다면 클라이언트 기본 설정을 따르세요. 활성화 직후 일반 도메인, LAN 주소와 시스템 프록시를 따르지 않는 프로그램을 각각 확인하세요. 어느 한 종류에서든 이상이 발생하면 별도로 기록하고 “웹페이지가 열리는가”만으로 결과를 요약하지 마세요.

엄격한 라우팅과 트래픽 루프

TUN에서는 클라이언트 자체가 서버로 보내는 연결이 다시 TUN으로 들어가 루프를 형성하지 않도록 해야 합니다. 그래픽 클라이언트는 보통 커널 프로세스, 서버 주소 또는 특정 인터페이스를 자동으로 제외합니다. 라우팅을 수동으로 수정할 때도 이런 제외 규칙을 유지해야 합니다. TUN을 켠 뒤 로그에 연결이 빠르게 반복되고 트래픽 수치가 비정상적으로 증가하지만 어떤 요청도 완료되지 않는다면 전형적인 루프 현상입니다. 이때는 먼저 TUN을 끄고 노드를 계속 바꾸지 마세요. 네트워크를 복구한 뒤 제외 라우트를 확인하세요.

엄격한 라우팅은 트래픽 우회를 줄이지만 가상 머신, 컨테이너, LAN 검색과 기업 내부 네트워크에 영향을 줄 수 있습니다. 활성화 후 LAN 기기가 사라지면 사설 주소가 직접 연결되는지, 멀티캐스트와 브로드캐스트가 가로채지는지, 현재 활성 인터페이스의 우선순위가 어떤지 확인하세요. Windows 가상 네트워크 카드, macOS 네트워크 확장과 Linux 정책 라우팅의 구현은 서로 다르므로 한 플랫폼에서 내보낸 라우팅 테이블을 다른 플랫폼에 그대로 적용할 수 없습니다.

DNS 요청이 거치는 계층

도메인에 접속할 때 앱은 시스템 DNS, 브라우저 내장 해석기, 암호화 DNS 또는 클라이언트가 가로채는 DNS를 사용할 수 있습니다. 클라이언트 로그에 도메인 요청이 나타나지 않는다고 해서 앱이 네트워크에 연결하지 않은 것은 아닙니다. 앱이 직접 해석했을 수 있습니다. 반대로 주소가 해석되었다고 아웃바운드 연결까지 성공하는 것도 아닙니다. 문제 해결은 두 단계로 나누세요. 먼저 도메인이 정상적인 주소로 해석되는지 확인하고, 그 주소로의 연결을 어느 아웃바운드가 처리하는지 확인합니다.

TUN을 켜면 클라이언트가 시스템 DNS를 인계받아 설정된 서버로 요청을 전달할 수 있습니다. 모든 도메인에서 실패하지만 주소로 직접 접속할 수 있다면 DNS 수신 포트, 상위 DNS 연결 가능 여부와 포트 충돌을 중점적으로 확인하세요. 일부 도메인만 비정상적으로 해석되면 분할 DNS, 캐시와 도메인 규칙을 확인합니다. DNS를 변경한 뒤에는 관련 연결을 재시작하거나 시스템 캐시를 비워야 합니다. 그렇지 않으면 앱이 이전 결과를 계속 사용할 수 있습니다.

현상	우선 확인할 항목	비교 방법
모든 도메인 접속 실패	DNS 수신, 상위 DNS, 포트 사용 여부	TUN을 끈 뒤 시스템 해석 확인
LAN 도메인만 실패	로컬 DNS, 사설 도메인 규칙	LAN 주소로 직접 접속
해석은 성공했지만 연결 시간 초과	노드, 아웃바운드, 라우팅 규칙	연결 단계 로그 확인
노드를 바꿔도 이전 결과 사용	시스템 및 앱 DNS 캐시	앱 재시작 및 재연결

Fake DNS 및 도메인 매핑

일부 TUN 설정은 Fake DNS를 사용합니다. 먼저 앱에 내부 매핑 주소를 반환한 뒤 클라이언트가 연결을 받을 때 원래 도메인을 복원하는 방식입니다. 이 방식은 도메인 정보를 유지하고 라우팅을 실행하는 데 도움이 되지만 매핑 주소 대역, 라우팅과 클라이언트 상태가 일치해야 합니다. 클라이언트가 종료된 뒤에도 매핑이 시스템이나 앱에 캐시되어 있으면 접속이 일시적으로 실패할 수 있습니다. 이 경우 TUN을 끄고 시스템 DNS를 복원한 뒤 관련 캐시를 비우고 다시 연결하세요.

Fake DNS를 다른 로컬 DNS 서비스와 무작정 함께 사용하지 마세요. 시스템에 광고 차단 DNS, 로컬 개발용 해석기 또는 컨테이너 DNS가 이미 있다면 먼저 요청 경로를 정리해야 합니다. 누가 로컬 포트를 수신하고, 누가 상위 서버이며, 어느 구성 요소가 도메인 규칙을 담당하는지 확인하세요. 두 서비스가 같은 포트를 사용하면 시작 자체가 실패하고, 서로 순환 전달하면 계속 시간 초과가 발생합니다. 안정적인 구성에는 명확한 시스템 진입점 하나만 두고 그곳에서 다음 서비스로 전달하세요.

LAN, 핫스팟 및 가상 환경

TUN을 켠 뒤 NAS, 프린터, 라우터 관리 페이지에 접속하지 못하는 것은 보통 사설 주소 라우팅이나 로컬 DNS와 관련이 있습니다. 먼저 기기 주소로 직접 접속하세요. 주소는 도달하지만 호스트 이름만 안 되면 로컬 DNS를 처리하고, 주소도 도달하지 않으면 사설 네트워크 대역이 잘못 프록시로 보내지는지 확인하세요. 기기에서 핫스팟을 공유할 때 다른 기기의 트래픽이 TUN으로 들어가는지는 시스템 전달 설정과 클라이언트 기능에 따라 달라지므로 본기기의 연결 상태만으로 판단할 수 없습니다.

가상 머신과 컨테이너는 독립적인 브리지, DNS와 라우팅을 사용하는 경우가 많습니다. 호스트의 시스템 프록시가 가상 환경에 자동으로 적용되는 것은 아니며, TUN도 인터페이스 우선순위에 따라 일부 트래픽만 적용할 수 있습니다. 문제를 해결할 때는 호스트와 가상 환경에서 기본 라우트와 DNS를 각각 확인하고 컨테이너 내부 연결 실패를 노드 문제로 단정하지 마세요. 개발 도구만 프록시를 사용하면 된다면 TUN 적용 범위를 넓히기보다 도구나 환경에 로컬 프록시 주소를 명시하는 편이 관리하기 쉽습니다.

안정적인 시작 및 종료 순서

활성화 순서는 기본 네트워크 사용 가능 여부 확인, 클라이언트 시작, 구독 업데이트 및 노드 선택, 시스템 프록시 검증, TUN 활성화를 권장합니다. 종료할 때는 먼저 TUN을 중지하고 가상 인터페이스와 추가 라우트가 정리되었는지 확인한 뒤 시스템 프록시를 복원하고 마지막으로 클라이언트를 종료하세요. 시스템이 비정상적으로 재시작된 후 네트워크가 되지 않으면 반대 순서로 잔류 상태를 확인합니다. 시스템 프록시가 로컬을 가리키는지, 가상 인터페이스가 남아 있는지, DNS가 중지된 수신 포트를 가리키는지 점검하세요.

이 장의 확인 기준은 TUN을 켜고 끌 때 네트워크 상태를 예측할 수 있고, LAN 범위가 명확하며, DNS 진입점이 하나이고, 클라이언트 종료 후 시스템이 복구되는 것입니다. 시스템 프록시만으로 실제 앱이 충분히 적용된다면 더 단순한 설정을 유지해도 됩니다. 적용 범위가 넓다고 현재 기기에 더 적합한 것은 아닙니다.

08 / TROUBLESHOOTING

일반적인 설정 문제와 계층별 해결

먼저 문제를 계층화하세요

효율적인 문제 해결은 문제가 어느 계층에 있는지 먼저 판단하는 데서 시작합니다. 첫 번째 계층은 기기의 기본 네트워크로, 클라이언트를 끈 상태에서 직접 연결이 정상이어야 합니다. 두 번째는 구독과 설정으로, 클라이언트가 노드를 해석해 내야 합니다. 세 번째는 커널 연결로, 로그에 아웃바운드 연결 수립 또는 명확한 오류가 표시되어야 합니다. 네 번째는 시스템 가로채기로, 앱 트래픽이 로컬 프록시 또는 TUN으로 들어가야 합니다. 다섯 번째는 라우팅과 DNS로, 요청이 예상한 아웃바운드로 전달되어야 합니다. 앞 단계들을 건너뛰고 고급 매개변수부터 바꾸면 대개 현상만 복잡해집니다.

한 번에 하나의 변수만 바꾸고 변경 전후 결과를 기록하세요. 예를 들어 노드에 연결할 수 없다면 같은 네트워크에서 먼저 노드 하나를 바꿔 봅니다. 모두 실패하면 구독과 네트워크를 확인하고, 하나만 실패하면 해당 노드 설정 문제일 가능성이 높습니다. 브라우저는 실패하지만 클라이언트 테스트가 성공하면 시스템 프록시를 확인하세요. 시스템 프록시는 정상인데 특정 독립 앱만 실패하면 앱 프록시 또는 TUN을 점검합니다. 이런 비교가 반복적인 재설치보다 훨씬 많은 정보를 제공합니다.

구독 업데이트 실패

구독 업데이트가 실패하면 먼저 주소가 완전하고 앞뒤에 공백이 없으며 단일 노드 가져오기 메뉴가 아닌 구독 설정에 추가되었는지 확인하세요. 그다음 업데이트 안내가 네트워크 요청 실패인지, 빈 응답인지, 해석 실패인지 확인합니다. 요청 실패는 기본 네트워크가 복구된 뒤 다시 시도하고, 빈 응답은 구독 출처의 상태를 확인하며, 해석 실패는 클라이언트가 반환 형식을 지원하는지 점검하세요. 구독 주소를 공유 링크로 바꾸거나 불필요해 보이는 쿼리 매개변수를 직접 삭제하지 마세요.

업데이트에는 성공했지만 새 노드가 추가되지 않았다면 현재 보고 있는 그룹, 필터 조건과 중복 처리 규칙을 확인하세요. 일부 구독 업데이트는 기존 그룹에 추가하지 않고 덮어씁니다. 서버의 노드가 바뀌지 않았다면 목록도 그대로인 것이 정상입니다. 기존 노드는 작동하지만 새 노드만 보이지 않으면 임시 그룹을 만들어 업데이트 결과를 비교할 수 있습니다. 확인이 끝나면 임시 그룹을 병합하거나 삭제해 장기적인 중복을 피하세요.

노드를 선택했지만 연결할 수 없음

먼저 시스템 시간, 현재 네트워크와 노드 매개변수를 확인하세요. 로그의 시간 초과는 보통 연결이 완료되지 않았다는 뜻으로, 주소에 도달할 수 없거나 네트워크 패킷이 손실되었거나 서버가 응답하지 않는 경우일 수 있습니다. 연결 거부는 대상 주소에는 도달했지만 해당 포트가 연결을 받아들이지 않는다는 뜻입니다. 설정 해석 오류는 매개변수 구조에 문제가 있음을 의미합니다. TLS, 서버 이름, 전송 경로와 서비스 이름 등의 필드는 노드 출처와 일치해야 하며 경험에 따라 흔한 값으로 바꾸지 마세요.

같은 노드가 한 플랫폼에서는 작동하지만 다른 플랫폼에서 실패한다면 노드 이름만 비교하지 말고 양쪽의 프로토콜 필드와 커널 기능을 비교하세요. 내부 JSON을 복사하는 것보다 원본 구독에서 다시 가져오는 편이 안정적입니다. v2rayNG은 특정 확장을 가져오지만 v2flyNG가 인식하지 못한다면 커널 계열에 맞는 호환 클라이언트를 선택하세요. 누락된 필드를 비워 둔 채 강제로 연결하지 마세요.

클라이언트는 연결됨으로 표시되지만 앱에는 변화가 없음

대개 시스템 가로채기 계층의 문제입니다. 데스크톱 플랫폼에서는 시스템 프록시가 클라이언트의 현재 수신 포트를 가리키는지 확인하고, Android에서는 시스템 VPN 확인을 완료했는지 확인하세요. 이어서 앱이 시스템 프록시를 읽는지, 연결 전에 장시간 연결을 이미 만들어 둔 것은 아닌지 확인합니다. 앱을 완전히 종료한 뒤 다시 열면 연결 캐시를 배제할 수 있습니다. 브라우저에 별도의 프록시 확장 프로그램이 설정되어 있다면 시스템 설정을 덮어쓰지 않도록 잠시 비활성화하세요.

명령줄 프로그램은 프록시 환경 변수를 확인해야 하고, 게임과 독립 네트워크 스택 앱에는 TUN이 필요할 수 있습니다. 한 앱이 시스템 프록시를 무시한다고 노드를 사용할 수 없다고 판단하지 마세요. 시스템 프록시를 확실히 따르는 브라우저를 기준 샘플로 삼아 정상 작동을 확인한 뒤 적용 범위를 넓히세요.

클라이언트 종료 후 인터넷에 연결할 수 없음

가장 흔한 원인은 시스템 프록시가 이미 중지된 로컬 포트를 계속 가리키는 것입니다. Windows와 macOS에서는 시스템 네트워크 설정에서 수동 프록시 또는 자동 프록시 설정을 끄고, Linux에서는 데스크톱 프록시와 터미널 환경 변수를 확인하세요. Android에서는 시스템 연결 상태와 항상 켜짐 설정을 확인합니다. TUN을 사용한 적이 있다면 가상 인터페이스, 기본 라우트와 DNS가 복구되었는지도 확인하세요. 완료 후 직접 연결을 먼저 검증하고 클라이언트를 다시 시작하세요.

프로세스를 강제 종료하면 정상 종료보다 상태가 남기 쉽습니다. 장기간 사용할 때는 클라이언트 메뉴에서 시스템 프록시와 TUN을 끈 뒤 종료하세요. 시스템을 재시작할 때마다 같은 문제가 반복되면 중복 자동 시작 항목이 있는지, 다른 네트워크 도구가 로그인 시 프록시를 다시 설정하는지 확인하세요. 여러 프로그램이 하나의 시스템 프록시 스위치를 동시에 관리하지 않도록 하세요.

포트 사용 중 및 커널 시작 실패

로그에 포트가 이미 사용 중이라고 표시되면 먼저 다른 프록시 클라이언트를 종료하고 v2rayN, v2rayNG 또는 v2flyNG가 중복 실행되고 있지 않은지 확인하세요. 이전 비정상 종료로 커널 프로세스가 남아 있을 수도 있습니다. 필요 없는 기존 프로세스를 종료한 뒤 다시 시작하세요. 수신 포트를 반드시 바꿔야 한다면 브라우저, 터미널 환경 변수와 해당 포트에 의존하는 다른 도구도 함께 업데이트해야 클라이언트는 새 포트를 사용하지만 앱은 이전 값을 사용하는 일이 발생하지 않습니다.

# Linux에서 지정 포트를 수신 중인 프로세스 확인
ss -lntp

# Windows PowerShell에서 TCP 수신 확인
Get-NetTCPConnection -State Listen

# macOS에서 TCP 수신 확인
lsof -nP -iTCP -sTCP:LISTEN

용도를 확인할 수 없는 시스템 프로세스는 종료하지 마세요. 명령 결과는 포트와 프로세스의 대응 관계를 찾는 데 사용하고, 그다음 기존 클라이언트를 종료할지 새 클라이언트의 포트를 바꿀지 결정하세요. 수신 주소가 127.0.0.1이면 본기기에서만 접근할 수 있다는 뜻입니다. 모든 인터페이스에서 수신한다면 LAN 접근 설정과 방화벽도 확인해야 합니다.

TUN 활성화 후 전체 네트워크 중단

즉시 TUN을 끄고 기본 네트워크가 복구되는지 확인한 다음 권한, 가상 인터페이스, 라우팅, DNS 순서로 점검하세요. 권한 부족은 보통 인터페이스 생성 시점에 오류가 발생합니다. 라우팅 충돌은 인터페이스가 생성된 뒤 트래픽을 잘못된 경로로 보내며, DNS 문제는 도메인 접속 실패로 나타나는 경우가 많습니다. 가상 머신, 컨테이너 네트워크 또는 다른 가상 네트워크 카드 도구를 동시에 사용한다면 먼저 하나를 잠시 중지해 비교하세요.

Android에서는 다른 VPN 설정이 시스템에 남아 있는지도 확인해야 하며, 데스크톱 플랫폼에서는 여러 클라이언트가 동시에 자동 시작되는지 확인하세요. 복구 테스트에서 모든 기능을 한 번에 다시 켜지 마세요. 먼저 노드 연결, 다음 시스템 프록시, 마지막으로 TUN 순서로 진행합니다. 각 계층을 통과한 뒤 다음 단계로 넘어가야 문제가 어느 단계에서 생겼는지 알 수 있습니다.

로그 정리 및 추가 참고

문제를 문의하기 전에 운영체제, 클라이언트 이름, 설치 패키지 아키텍처, 시스템 프록시와 TUN 중 사용한 방식, 문제가 발생한 시간과 최근 변경 사항을 기록하세요. 로그는 장애 전후의 관련 구간만 잘라내고 구독 주소, 사용자 식별자와 서버 주소 등 민감한 내용은 숨기세요. “구독 업데이트 성공, 노드 선택 후 시스템 프록시 활성화, 브라우저 요청 시간 초과, 시스템 프록시를 끄면 직접 연결 복구”처럼 재현 가능한 단계로 설명하면 “사용할 수 없음”보다 원인을 찾기 쉽습니다.

여전히 판단하기 어렵다면 자주 묻는 질문에서 기본 개념, 설치 및 설정, 사용 팁과 문제 해결 분류를 따라 계속 확인하세요. 초보자는 V2Ray 초보자를 위한 10문 10답을 읽고 커널, 구독과 프록시 모드의 기본 관계를 확인할 수 있습니다. 문제 해결이 끝나면 임시 로그 수준, 테스트 포트와 임시 라우트를 해제하고 검증된 안정 설정을 하나 보관하세요.

전체 설정의 최종 확인은 네 가지 상태를 포함해야 합니다. 클라이언트가 시작된 뒤 구독을 업데이트할 수 있고, 노드 연결 후 대상 앱이 예상대로 프록시를 사용하며, 시스템 프록시 또는 TUN을 끈 뒤 직접 연결이 복구되고, 기기를 재시작하거나 네트워크를 전환한 뒤 다시 연결할 수 있어야 합니다. 이 네 가지를 충족하면 설치, 설정, 시스템 가로채기와 복구 경로가 모두 완성된 것입니다.