V2Ray 자주 묻는 질문

아닙니다. V2Ray는 Project V 프록시 도구 생태계에 속하며, V2Fly는 관련 코어를 커뮤니티에서 이어서 관리합니다. Xray는 별도의 코어 계열로, 지원하는 프로토콜과 기능은 버전에 따라 달라집니다. v2rayN은 서버, 구독, 라우팅과 코어 실행을 관리하는 그래픽 클라이언트입니다. 설정을 가져온 뒤 실제 연결을 처리하는 것은 클라이언트가 실행한 코어입니다. 프로토콜을 지원하지 않거나 실행 오류가 발생하면 창에 표시된 제품명만 볼 것이 아니라 클라이언트와 코어 정보를 함께 확인해야 합니다. 특히 REALITY 같은 설정은 서버 요구 사항과 현재 코어의 지원 여부가 맞는지 확인하세요. 프로토콜 이름만 바꿔서는 해결되지 않습니다.

Windows, macOS, Linux 데스크톱에서는 v2rayN을 우선 고려하고, 운영체제와 프로세서 아키텍처에 맞는 설치 파일을 선택하세요. Android에서는 Xray 코어를 사용하는 v2rayNG 또는 V2Fly 코어를 사용하는 v2flyNG를 선택할 수 있습니다. 먼저 서비스 제공자가 안내한 프로토콜, 전송 방식, 보안 설정을 확인한 뒤 클라이언트에 포함된 코어가 이를 지원하는지 살펴보세요. 두 Android 클라이언트의 설정 화면과 기능은 완전히 같지 않으므로 한쪽의 모든 옵션을 다른 쪽에 그대로 적용하지 않는 것이 좋습니다. 현재 설정이 안정적으로 작동한다면 먼저 백업하고, 클라이언트를 바꿀 필요가 있는지 검토하세요. 이름만 바꾼다고 서버 품질이 좋아지지는 않습니다.

클라이언트는 설정을 읽고 연결을 생성하는 역할을 하며, 설치 파일에 서버가 포함되어 있지는 않습니다. 사용 권한이 있는 서비스 제공자에게 구독 링크, 공유 링크 또는 수동 설정 정보를 받아 클라이언트에 가져와야 합니다. 구독은 서버 설정을 업데이트할 수 있는 링크이고, 공유 링크는 보통 하나의 설정만 담습니다. 각각에 맞는 가져오기 방법을 사용하세요. 결제 페이지나 로그인 페이지, 일반 웹 주소를 구독 주소로 사용하면 안 됩니다. 구독 링크에는 접속 인증 정보가 포함될 수 있으므로 민감 정보로 취급하고 스크린샷, 게시판, 로그에 공개하지 마세요. 출처가 불분명한 링크는 바로 가져와 사용하지 않는 것이 좋습니다.

시스템 프록시는 운영체제의 프록시 설정에 로컬 프록시 주소를 지정하며, 일반적으로 해당 설정을 따르는 앱만 이를 사용합니다. TUN은 가상 네트워크 어댑터와 시스템 라우팅을 이용해 트래픽을 처리하므로 적용 범위가 넓지만, 필요한 권한이 있어야 하며 다른 가상 어댑터나 VPN과 충돌할 수 있습니다. 라우팅 규칙은 코어에 들어온 요청을 어떤 아웃바운드로 보낼지 결정하며, 모든 앱의 트래픽을 자동으로 클라이언트에 보내지는 않습니다. 문제를 확인할 때는 트래픽이 클라이언트에 들어오는지와 들어온 뒤 어디로 향하는지를 따로 살펴보세요. 처음 설정할 때는 시스템 프록시로 웹 접속을 테스트하고, 노드가 정상임을 확인한 다음 TUN을 활성화하면 권한, DNS, 노드 문제를 혼동하지 않을 수 있습니다.

2015년 이후 출시된 대부분의 Android 스마트폰에서는 arm64를 먼저 고려할 수 있지만, 최종적으로는 기기가 지원하는 앱 아키텍처를 확인해야 합니다. 구매 연도만으로 판단하지 마세요. 일부 기기는 64비트 프로세서를 사용해도 시스템이 32비트 앱만 지원해 arm64 설치에 실패할 수 있습니다. universal 패키지는 여러 아키텍처를 포함해 대체로 용량이 크며, 아키텍처를 모르거나 arm64를 설치할 수 없는 경우에 적합합니다. 패키지를 바꾸기 전에는 시스템 버전, 남은 저장 공간, 설치 오류 메시지를 확인하세요. 같은 이름의 앱이 이미 설치되어 있다면 서명 차이로 업데이트 설치가 차단될 수 있습니다. 필요한 경우 설정을 먼저 백업한 뒤 기존 앱을 삭제할지 결정하세요.

먼저 구독 주소 전체를 복사했는지 확인하세요. 앞뒤 공백이나 줄바꿈, 안내 문구가 붙었거나 주소 끝부분이 잘리지 않았는지도 살펴보세요. v2rayN에서는 구독 그룹 설정에 구독 주소를 추가한 뒤 업데이트해야 합니다. 서버 공유 링크 하나를 가져올 때는 해당 서버 가져오기 메뉴를 사용하세요. 메뉴를 잘못 선택하면 구문 분석에 실패할 수 있습니다. 링크를 가져오는데도 오류가 난다면 응답 내용이 로그인 페이지나 만료 안내인지, 클라이언트가 지원하지 않는 형식인지 확인하세요. 브라우저에서 주소가 열린다는 이유만으로 구독이 유효하다고 판단하면 안 됩니다. 원래 링크를 보관하고 제공자에게 호환되는 클라이언트와 형식을 확인하세요. 주소의 매개변수를 임의로 수정하지 마세요.

먼저 서비스 계정과 구독 유효 기간을 확인하고, 제공자가 주소를 변경했는지도 살펴보세요. 현재 네트워크에서 구독 서비스에 접속할 수 있는지도 확인해야 합니다. 업데이트 요청 중에는 기존 프록시를 통해 보내야 하는 경우도 있고 직접 연결해야 하는 경우도 있습니다. 클라이언트의 업데이트 옵션과 제공자 안내에 따라 선택하고 무작정 바꾸지 마세요. 가져오기는 성공했지만 노드가 없다면 콘텐츠 형식, 서버 필터 조건, 코어 호환성을 확인하세요. 업데이트 전에 계속 사용할 수 있는 설정을 보관하고 구독 그룹 전체를 바로 삭제하지 마세요. 서버가 빈 응답을 보냈다면 버튼을 반복해서 눌러도 대개 해결되지 않습니다. 오류 문구와 발생 시각을 기록하고, 문의할 때는 구독 링크 전체를 숨기세요.

먼저 TUN을 끄고 일반 프록시 연결이 되는지 확인한 다음 시스템 권한을 점검하세요. Windows에서는 클라이언트 안내에 따라 관리자 권한으로 실행하거나 서비스 모드가 올바르게 설치되고 시작되었는지 확인합니다. macOS와 Linux에서는 해당 버전의 안내에 따라 필요한 권한을 허용하세요. Android에서는 시스템 VPN 권한 요청 창에서 현재 사용 중인 클라이언트에 권한을 부여해야 합니다. 트래픽을 가로채는 앱은 한 번에 하나만 실행하는 것이 좋습니다. 권한을 허용했는데도 오류가 나면 로그에서 가상 네트워크 어댑터, 장치 생성, 라우팅 설정 오류를 확인하세요. 처음부터 모든 보안 기능을 끄거나 출처가 불분명한 곳에서 드라이버를 설치하지 마세요.

클라이언트가 실행 중이고 서버가 선택되어 있는지, 시스템 프록시가 실제로 활성화되어 있는지 먼저 확인하세요. 그런 다음 시스템에 설정된 프록시 주소와 포트가 현재 로컬 수신 설정과 일치하는지 살펴보세요. 브라우저 확장 프로그램, 별도 프록시 설정, 우회 목록, PAC 규칙에 따라 실제 연결 경로가 달라질 수 있습니다. 일부 앱은 시스템 설정을 다시 읽기 위해 재시작해야 하고, 시스템 프록시를 전혀 사용하지 않는 앱도 있습니다. 브라우저 프록시 확장 프로그램을 잠시 끄고 프록시를 사용해야 하는 요청을 보낸 뒤 클라이언트 로그에 연결 기록이 남는지 확인하세요. 기록이 없다면 트래픽 진입 경로를 먼저 점검하고, 기록이 있다면 라우팅과 노드를 확인하세요. 웹페이지가 열린다는 것만으로 프록시가 적용되었다고 판단하지 마세요.

먼저 직접 연결할 도메인이나 주소 범위를 정한 뒤 라우팅 설정에 해당 규칙을 추가하고 직접 연결 아웃바운드를 선택하세요. 규칙은 대개 순서대로 적용되며 실제 동작은 코어와 생성된 설정에 따라 달라집니다. 범위가 넓은 규칙에 덮이지 않도록 명확한 예외 규칙을 앞쪽에 배치하세요. 도메인 규칙과 IP 규칙은 서로 같지 않으며 DNS 조회 결과도 규칙 적용에 영향을 줄 수 있습니다. 한 번에 조건 하나만 바꾸고 설정을 적용한 뒤 실제 접속과 로그로 아웃바운드 선택을 확인하세요. 사이트 하나 때문에 전체를 직접 연결로 바꾸거나 규칙 우선순위를 모른 채 여러 규칙 세트를 한꺼번에 가져오지 마세요. 복잡한 정책은 먼저 백업하고 나누어 검증하세요.

반드시 그런 것은 아닙니다. 시스템 DNS, 브라우저의 보안 DNS, 코어 DNS는 서로 다른 계층이며 클라이언트를 거치는지는 프록시 모드, 요청 방식, 라우팅 설정에 따라 달라집니다. 먼저 문제가 도메인 조회인지 연결 자체인지 확인한 뒤 어느 계층을 조정할지 결정하세요. 브라우저에서 별도의 보안 DNS를 사용하면 시스템에서 확인한 결과와 다를 수 있습니다. TUN 모드에서는 DNS 가로채기가 활성화되어 있는지도 확인해야 합니다. 설정을 바꾸기 전에 기존 값을 기록하고 한 번에 변수 하나만 변경하세요. 필요하면 관련 캐시를 지운 뒤 다시 테스트합니다. 여러 DNS 서비스를 동시에 바꾸고 FakeDNS까지 켜면 어떤 설정이 문제를 해결했거나 일으켰는지 파악하기 어렵습니다.

두 기기가 서로 통신할 수 있는 신뢰할 수 있는 로컬 네트워크에 연결되어 있는지 확인하세요. v2rayN에서 로컬 네트워크 연결을 허용하고 로컬 HTTP 또는 SOCKS 수신 포트를 확인합니다. 다른 기기에는 루프백 주소가 아니라 컴퓨터의 로컬 네트워크 주소와 해당 포트를 입력해야 합니다. 시스템 방화벽에서는 신뢰할 수 있는 네트워크에 한해 필요한 포트만 허용하세요. 라우터의 게스트 네트워크 격리 기능이 접속을 막을 수도 있습니다. 기기의 프록시 설정은 수신 프로토콜과 일치해야 하며, 많은 TV와 앱은 시스템 프록시를 따르지 않습니다. 공유가 끝나면 로컬 네트워크 연결 허용을 끄고 포트를 공용 인터넷에 노출하지 마세요. 컴퓨터가 절전 모드에 들어가거나 IP 주소가 바뀌거나 클라이언트가 종료되면 공유 연결이 끊깁니다.

먼저 프록시를 끄고 컴퓨터의 기본 네트워크가 정상인지 확인한 다음 시스템 시간을 맞추세요. 올바른 서버와 실행 모드를 선택했는지도 살펴봅니다. 이어서 서버 주소, 포트, 사용자 매개변수, 전송 방식, TLS 또는 REALITY 설정을 확인하고 마지막으로 DNS와 코어 로그를 살펴보세요. 한 번에 한 항목만 바꾸고 원래 설정은 보관하세요. TCP 연결 테스트, 실제 프록시 요청, 속도 측정은 서로 다른 테스트입니다. 테스트가 시간 초과되었다고 모든 연결을 사용할 수 없는 것은 아닙니다. 다른 정상 노드는 작동한다면 해당 서버나 매개변수에 문제가 있을 가능성이 높습니다. 모든 노드가 실패하면 컴퓨터 네트워크, 프록시 진입 경로, 코어 실행 여부부터 확인하세요.

연결됨 표시는 로컬 코어나 VPN 서비스가 시작되었다는 뜻일 뿐, 원격 서버가 요청을 처리할 수 있다는 보장은 아닙니다. 웹페이지에 접속할 때 연결 로그가 생성되는지 먼저 확인하세요. 로그가 없으면 시스템 프록시, 앱 자체 프록시, TUN 적용 여부를 살펴봅니다. 로그가 있다면 아웃바운드, DNS, 핸드셰이크, 시간 초과 정보를 확인하세요. 여러 사이트에 접속해 특정 사이트 문제인지 전체 연결 문제인지 비교해 볼 수 있습니다. 정상 작동하는 설정으로 바꿔 해결되었다면 기존 노드의 매개변수와 서비스 상태를 다시 확인하세요. 요청이 클라이언트에 들어오는지 확인하기 전에 DNS를 반복해서 바꾸지 말고, 트레이 아이콘이나 Android VPN 표시만으로 연결이 정상이라고 판단하지 마세요.

먼저 TUN을 끄고 기존 연결 방식으로 되돌린 뒤 오류 로그를 보관하세요. 그런 다음 권한, 가상 네트워크 어댑터, DNS 가로채기, 라우팅이 정상적으로 설정되었는지 확인합니다. 다른 VPN, 가상 머신 네트워크, 보안 소프트웨어가 TUN과 충돌할 수 있으므로 관련 앱을 하나씩 종료해 테스트하세요. 모든 설정을 한꺼번에 바꾸지 마세요. FakeDNS를 사용한다면 관련 라우팅과 DNS 설정이 함께 맞는지도 확인해야 합니다. 기본 TUN부터 정상 작동하지 않는다면 일반 DNS 처리 방식으로 되돌려 보세요. 클라이언트를 종료한 뒤에도 인터넷이 되지 않으면 남아 있는 시스템 프록시와 비정상 네트워크 어댑터를 확인하세요. 필요하면 시스템을 재시작해 복구한 뒤 단계별로 다시 시도하고, 시스템 네트워크 구성 요소를 바로 삭제하지 마세요.

운영체제, 클라이언트와 코어 정보, 사용 모드, 실패 단계, 발생 시각, 관련 오류 로그를 제공하면 됩니다. 문제를 한 번 재현한 뒤 같은 시간대의 실행 오류나 연결 오류를 추려 내고, 직접 연결은 정상인지, 다른 설정은 작동하는지, 최근에 무엇을 변경했는지 함께 설명하세요. 전체 구독 주소, 사용자 식별 정보, 비밀번호, 개인 키, 원본 설정 전체를 공개하지 마세요. 스크린샷에 주소창이나 서버 세부 정보가 보이는지도 확인해야 합니다. 로그의 시간 초과, DNS 조회 실패, 권한 거부, 핸드셰이크 오류는 서로 다른 문제를 가리킵니다. 단순히 안 된다고 적기보다 오류 원문을 보존하는 편이 도움이 됩니다. 로그를 공유하기 전에 디버그 기록에 민감한 요청 정보가 포함되지 않았는지 확인하세요.