클라이언트 자주 묻는 질문

Windows, macOS, Linux에서는 v2rayN을, Android에서는 보통 Xray 코어를 사용하는 v2rayNG를 선택합니다. V2Fly 설정과 호환되어야 한다면 v2flyNG도 고려해 보세요. 운영체제를 먼저 확인한 뒤 서버에서 요구하는 프로토콜, 전송 방식, 보안 설정을 살펴보세요. 세 클라이언트는 메뉴와 설정 지원 범위가 서로 달라 이름이 비슷하다고 설정을 그대로 바꿔 쓸 수는 없습니다. REALITY 같은 설정을 사용한다면 해당 코어와 클라이언트 버전에서 필요한 항목을 지원하는지도 확인하세요.

클라이언트는 설정을 읽고 연결을 구성하며 라우팅 규칙을 적용하지만, 설치만으로 사용할 수 있는 서버가 제공되지는 않습니다. 시작하기 전에 사용 권한이 있는 구독 URL, 공유 링크 또는 서버 설정 정보를 준비하고 주소, 포트, 인증 정보, 전송 및 보안 설정이 모두 있는지 확인하세요. 구독 URL과 공유 링크에는 접속 정보가 포함될 수 있으므로 공개 게시판에 올리거나 설정 화면의 QR 코드를 다른 사람에게 보내지 마세요. 일부 설정만 받은 경우 필요한 정보를 먼저 확인한 다음 가져오기와 연결을 시도하세요.

VLESS는 프록시 프로토콜이고 REALITY는 전송 보안 방식이며 Xray는 이 설정을 실행하는 코어입니다. 서로 같은 단계에서 바꿔 쓸 수 있는 선택지가 아닙니다. 클라이언트에서는 프로토콜로 VLESS를 선택하고 보안 설정으로 REALITY를 지정한 뒤 서버 요구에 따라 전송 방식과 관련 값을 입력하는 경우가 많습니다. 프로토콜 이름만 REALITY로 바꾸거나 코어만 전환한다고 빠진 항목이 채워지지는 않습니다. 설정이 지원되지 않는다면 먼저 클라이언트와 코어의 지원 범위를 확인하고 서버에서 요구한 조합과 대조하세요.

데스크톱의 시스템 프록시는 해당 설정을 따르는 앱에 프록시 주소를 전달하지만, 이를 무시하는 프로그램도 있습니다. TUN은 가상 네트워크 인터페이스로 규칙에 맞는 트래픽을 처리하며 권한, 라우팅, DNS 설정이 필요할 수 있습니다. Android의 v2rayNG는 시스템 VPN 인터페이스를 통해 로컬 트래픽 전달 경로를 만들며, 처음 연결할 때 시스템 권한을 요청합니다. 그렇다고 모든 트래픽이 원격 서버를 거치는 것은 아니며 실제 경로는 라우팅 규칙과 앱 범위 설정에 따라 달라집니다. 문제를 확인할 때는 먼저 한 가지 방식만 선택해 여러 프록시 도구의 경로가 겹치지 않도록 하세요.

최근 Android 스마트폰은 대체로 arm64를 지원하지만, 프로세서 모델이나 구매 연도가 아니라 기기의 운영체제가 지원하는 앱 아키텍처를 기준으로 선택해야 합니다. 시스템에서 64비트 ARM 앱을 지원하는지 확인했다면 arm64를 선택하세요. 아키텍처를 모르겠다면 여러 아키텍처를 포함하는 universal을 선택할 수 있지만 파일 크기가 더 큽니다. 설치 중 패키지를 파싱할 수 없다는 메시지가 나오면 Android 버전 요구 사항, 다운로드 완료 여부, 기존 버전과 서명 충돌 여부도 확인하세요. 기존 클라이언트를 바로 삭제하지 말고 필요한 설정을 먼저 내보낸 뒤 다음 단계를 결정하세요.

복사한 내용이 구독 URL인지 단일 공유 링크인지 먼저 확인하세요. 구독 URL은 구독 그룹에 추가하고, 공유 링크는 클라이언트가 지원하는 링크 가져오기 기능을 사용해야 합니다. 클립보드에 안내 문구, 줄바꿈, 앞뒤 공백, 메신저가 덧붙인 문장부호가 섞이지 않았는지 확인한 다음 앱에서 클립보드에 접근할 수 있는지도 살펴보세요. 구독 그룹을 만들었는데 목록이 비어 있다면 구독 업데이트를 실행해야 합니다. URL을 저장한 것만으로 구독 정보를 가져왔다고 볼 수는 없습니다. 계속 실패하면 업데이트 로그를 확인해 URL에 접속할 수 없는 문제인지, 응답 내용을 해석하지 못하는 문제인지 구분하세요.

v2rayNG로 처음 연결할 때 시스템에 표시되는 VPN 연결 요청에서 허용을 선택해야 합니다. 거부했다면 연결을 중지한 다음 다시 시작해 권한을 승인하세요. VPN 인터페이스를 사용하는 다른 앱, 업무 프로필 정책, 상시 VPN 제한이 있는지도 확인하세요. 데스크톱 TUN은 클라이언트 안내에 따라 필요한 서비스를 설치하거나 활성화하고 권한을 부여해야 하므로 Android 절차를 그대로 적용할 수 없습니다. 계속 실패하면 로그에서 권한 또는 가상 인터페이스 오류를 확인하세요. 시스템 권한 문제를 해결하려고 프로토콜을 반복해서 바꾸지 마세요.

현재 클라이언트의 내보내기 또는 백업 기능으로 구독 그룹, 직접 추가한 서버, 사용자 지정 라우팅 규칙을 저장하고 로컬 포트, DNS, 앱 범위 설정도 기록하세요. 백업 파일에는 인증 정보가 포함될 수 있으므로 안전하게 관리해야 합니다. 새 클라이언트로 가져온 뒤 설정 항목을 대조하고, 사용 가능한 것으로 확인된 설정 하나로 연결을 테스트하세요. 코어마다 지원하는 확장 항목이 달라 설정이 모두 옮겨지지 않을 수 있습니다. 다시 가져올 수 있는 구독 항목과 직접 수정한 항목은 따로 관리하고, 이전이 완료된 것을 확인한 뒤 기존 설정을 정리하세요. 재설치를 첫 단계로 삼지 마세요.

목적에 맞는 라우팅 프리셋을 선택한 다음 로컬 네트워크 주소, 직접 연결할 도메인, 기본 출구를 확인하세요. 사용자 지정 규칙은 보통 순서대로 적용되므로 구체적인 예외 규칙을 포괄적인 규칙보다 앞에 두고, 참조하는 geosite 및 geoip 데이터가 현재 코어에서 사용 가능한지도 확인해야 합니다. 페이지가 열리는지만으로 라우팅 결과를 판단하지 말고 클라이언트 로그에서 대상 주소와 출구 선택을 확인하세요. 규칙을 수정한 뒤에는 테스트 연결을 새로 만들고, 필요하면 앱의 기존 연결을 종료하세요. 연결이 재사용되면 이전 라우팅 결과가 계속 적용될 수 있습니다.

클라이언트에서 유효한 설정을 선택했고 코어가 정상적으로 시작됐는지 확인한 다음, 시스템 프록시가 실제로 활성화된 로컬 주소와 포트를 가리키는지 살펴보세요. SOCKS 10808과 HTTP 10809가 자주 쓰이지만 현재 클라이언트 설정을 기준으로 해야 하며 그대로 따라 입력해서는 안 됩니다. 브라우저 확장 프로그램, 앱 자체 프록시 설정, 다른 프록시 도구가 시스템 설정을 덮어쓰는지도 확인하세요. 수동 프록시를 지원하는 앱에서 같은 로컬 포트를 지정해 비교할 수 있습니다. 수동 프록시는 작동하지만 시스템 프록시는 작동하지 않는다면 해당 앱이 시스템 설정을 따르는지 확인하세요.

구독 항목은 보통 구독 응답 내용에 따라 관리되므로 업데이트 시 다시 생성되거나 교체될 수 있습니다. 오래 유지할 설정은 구독 항목에만 적용하지 않는 편이 좋습니다. 전송 방식, 메모, 기타 항목을 조정해야 한다면 클라이언트에서 허용하는 경우 별도 항목으로 복사하고 용도를 표시하세요. 별도 항목도 서버 설정이 바뀌면 작동하지 않을 수 있습니다. 라우팅 규칙, 구독 그룹 설정, 서버 항목은 서로 다른 설정 영역이므로 백업할 때 각각 확인하세요. 업데이트 후 선택한 서버가 아직 목록에 있는지 확인해 삭제되거나 교체된 항목을 계속 사용하지 않도록 하세요.

먼저 시스템이 앱을 종료하는 문제와 연결을 계속 재시도하는 문제를 구분하세요. 앱이 정리된 뒤 연결이 끊긴다면 전자일 가능성이 높고, 후자는 로그에 반복적인 연결 오류가 나타나는 경우가 많습니다. 필요하다면 클라이언트의 백그라운드 실행을 허용하고 배터리 최적화 및 자동 시작 제한을 확인하세요. 그렇다고 모든 앱의 절전 기능을 해제할 필요는 없습니다. 불필요한 자동 테스트, 잦은 구독 업데이트, 상세 로그의 상시 기록을 줄인 뒤 같은 네트워크에서 변화를 살펴보세요. 배터리 소모는 신호 품질, 전송 방식, 트래픽 양에도 영향을 받으므로 프로토콜 이름만으로 특정 설정이 더 절전된다고 단정할 수 없습니다.

로그에서 응답을 받았는지 먼저 확인하세요. 연결 시간 초과, 인증서 오류, 응답 내용 파싱 실패는 각각 다른 문제입니다. 구독 URL이 만료되지 않았는지, 인증 정보가 유효한지 확인하고 응답이 실제로 로그인 페이지, 오류 페이지 또는 클라이언트가 지원하지 않는 형식인지 살펴보세요. 업데이트에 기존 프록시가 필요하다면 해당 프록시가 먼저 정상 작동하는지 확인한 뒤 적절한 업데이트 방식을 선택하세요. 전체 구독 URL을 공개 게시물에 붙여 넣지 말고, 구독 그룹을 연달아 삭제하고 다시 만들지도 마세요. 기존 설정을 보존한 채 항목별로 점검하면 업데이트가 복구될 때까지 사용 가능한 서버를 계속 쓸 수 있습니다.

테스트 시간 초과는 제한 시간 안에 해당 테스트가 완료되지 않았다는 뜻일 뿐입니다. 테스트 주소, DNS, 연결 방식, 서버 상태가 영향을 줄 수 있으며 모든 트래픽을 사용할 수 없다는 의미는 아닙니다. 테스트가 TCP 연결 확인인지 실제 요청인지 먼저 살펴보고, 같은 설정으로 명확한 테스트 페이지에 접속하면서 로그를 확인하세요. 실제 요청도 실패한다면 주소, 포트, 인증, 전송 방식, 보안 설정을 순서대로 확인하고 다른 네트워크에서도 비교해 보세요. 테스트를 반복해 얻은 우연한 결과를 성능 결론으로 삼거나 숫자 하나만 보고 설정을 선택하지 마세요.

연결됨 표시는 보통 로컬 코어나 VPN 인터페이스가 시작됐다는 뜻이며 원격 연결, DNS, 라우팅까지 정상이라는 보장은 없습니다. 먼저 로그에 인증, 핸드셰이크, 이름 해석 오류가 있는지 확인하고 브라우저 트래픽이 실제로 클라이언트에 전달되는지도 살펴보세요. 도메인 이름을 해석하지 못한다면 DNS 설정과 요청 경로를 확인하세요. 일부 사이트만 열리지 않는다면 라우팅 규칙 적용과 대상 출구를 확인하고, 모든 요청이 실패한다면 서버 설정과 시스템 시간을 점검하세요. 원인을 파악하기 어려워지지 않도록 기존 값을 기록하고 한 번에 한 종류의 설정만 바꾸세요.

인증서 검증을 끄는 방법을 일반적인 해결책으로 권장하지 않습니다. 먼저 기기의 날짜와 시간, 서버 이름, 서버 인증서 설정, 프로토콜에 맞는 보안 항목을 확인하세요. TLS의 서버 이름과 연결 주소는 서로 다를 수 있으므로 서버에서 안내한 값에 맞춰 입력해야 합니다. REALITY를 사용한다면 공개 키와 short ID 등의 항목도 확인하세요. 이름을 임의로 바꾸는 것으로 올바른 설정을 대신할 수는 없습니다. 오류 유형과 발생 단계를 기록한 뒤 설정 제공자에게 필요한 항목을 문의하세요. 특정 네트워크에서만 오류가 발생하는지 다른 네트워크로 비교해 볼 수 있지만, 보안 옵션을 바꾸기 전에 먼저 원인을 파악해야 합니다.