구독 업데이트가 끝난 뒤의 노드 목록부터 시작해, 일반 지연과 실제 연결 지연 두 가지 테스트를 구분하고, 일괄 실제 연결 테스트로 사용 가능한 노드를 골라낸 다음, 앱 상태·출구 IP·대상 사이트 세 단계로 프록시 적용 여부를 확인합니다. v2rayNG를 막 설치했고 구독은 가져왔지만 아직 웹페이지가 열리지 않는 사용자에게 적합합니다.
구독 가져오기 후 노드 목록 읽는 방법
구독 업데이트가 끝나면 메인 화면 목록의 각 행이 하나의 노드 설정입니다. 왼쪽은 이름(비고), 오른쪽은 테스트 결과 자리로 기본값은 비어 있거나 지난번 테스트 값이 표시됩니다. 이름은 서버에서 내려주며 보통 지역명과 번호 조합이고, 이름일 뿐 회선 품질을 뜻하지 않으므로 중복 이름이나 깨진 문자도 정상입니다.
노드 항목 오른쪽 메뉴를 열면 '편집', '공유', '실제 연결 지연 테스트'가 보이고, 상단 메뉴에는 그룹 전체를 대상으로 하는 일괄 테스트도 있습니다. 첫 연결에서는 노드를 하나씩 눌러보며 운에 맡기지 말고, 먼저 일괄 테스트를 한 번 돌려 실제로 사용 가능한 몇 개로 범위를 좁히세요.
- 이름: 회선 구분용, 이름이 중복되거나 깨져도 비고를 기준으로 확인
- 프로토콜: VMess, VLESS, Trojan, SS 네 가지 일반 표기
- 전송: TCP, WebSocket, gRPC 등, CDN 중계 여부를 결정
- 테스트 결과: 지연 밀리초 수치 또는 '시간 초과', '실패' 표시
목록이 비어 있거나 구독 업데이트 후 항목 수가 그대로라면, 먼저 '구독 그룹'으로 돌아가 구독 주소가 유효한지, 업데이트 과정에 오류가 없었는지 확인한 뒤 테스트를 이야기하세요. 구독 자체가 만료되면 어떤 속도 테스트도 시간 초과만 잔뜩 나옵니다.
실제 연결 지연 테스트: 사용할 수 없는 노드 걸러내기
v2rayNG는 두 가지 테스트를 제공합니다. 일반 지연 테스트는 서버 주소와 포트로 TCP 왕복 한 번만 측정하므로 숫자가 좋아도 핸드셰이크가 된다는 보장은 없습니다. 실제 연결 지연 테스트는 프로토콜 핸드셰이크를 마친 뒤 탐지 주소로 요청을 한 번 보내고, 핸드셰이크와 첫 바이트까지 걸린 시간을 목록에 기록합니다. 첫 연결에서는 실제 연결 결과를 기준으로 삼으세요.
일괄 실행은 상단 메뉴의 '모든 구성 실제 연결 테스트'에서, 개별 노드는 항목 메뉴에서 '실제 연결 지연 테스트'를 선택합니다. 테스트 중에는 네트워크를 안정적으로 유지하고 노드를 동시에 전환하지 마세요. 테스트 중인 항목이 중단되어 결과가 무효가 됩니다.
결과 해석은 아래 표를 따르세요. 시간 초과와 실패는 대처 방식이 다르므로 무조건 다시 테스트하지 마세요.
| 목록 표시 | 의미 | 대처 방법 |
|---|---|---|
| 두 자리에서 세 자리 밀리초 | 핸드셰이크 완료, 탐지 요청 응답 있음 | 바로 사용 |
| 시간 초과 timeout | 핸드셰이크 또는 탐지 요청 무응답 | 같은 그룹의 다른 노드로 바꾸고 로컬 네트워크 문제도 점검 |
| 실패 failed | 핸드셰이크 단계에서 거부됨 | 구독을 다시 업데이트해 파라미터를 서버가 내려준 값으로 되돌리기 |
| 평소보다 눈에 띄게 높은 수치 | 회선 혼잡 또는 로컬 네트워크 불안정 | 몇 분 후 다시 측정해 판단 |
한 바퀴 돌린 뒤 지연이 낮고 시간 초과가 아닌 노드를 골라 하나를 활성화하세요. 나머지 사용 가능한 노드는 목록에 예비로 남겨두면 되고, 전부 활성화할 필요는 없습니다. 클라이언트는 동시에 하나의 구성만 사용하므로 여러 개를 켜도 의미가 없습니다.
프록시 적용 확인: 상태, 출구 IP, 대상 사이트
노드를 고른 뒤에는 아래 다섯 단계를 순서대로 진행하세요. 각 단계마다 확인할 지점이 분명하므로 감으로 판단할 필요가 없습니다.
노드 활성화
목록에서 속도 테스트를 통과한 노드를 선택하면, 알림창에 연결 상태가 나타나면서 코어가 시작됩니다.
코어 로그 확인
'설정' → '파라미터 설정'에서 로그 레벨을 '정보'로 올리고, 다시 연결한 뒤 시작 줄을 확인합니다.
출구 IP 비교
먼저 프록시를 끄고 출구 IP 조회 페이지에서 직결 IP를 기록한 다음, 프록시를 켜고 같은 페이지를 새로 고칩니다.
대상 사이트 접속
평소 프록시가 있어야 접속되는 사이트로 링크가 실제로 뚫렸는지 확인합니다.
사용 가능한 조합 기록
노드 이름, 라우팅 모드, 앱별 프록시 상태를 기록해 두고 네트워크 환경이 바뀔 때 우선 재사용하세요.
로그에 아래 두 줄이 나타나면 코어가 시작되고 로컬 포트가 준비된 것입니다. 두 줄이 없으면 대개 코어가 뜨지 않았거나 포트가 점유된 경우이니, '설정' → '파라미터 설정'에서 로컬 포트를 다른 값으로 바꾼 뒤 다시 연결하세요.
[Info] transport/internet/tcp: listening TCP on 127.0.0.1:10808
[Info] transport/internet/tcp: listening TCP on 127.0.0.1:10809출구 IP를 비교할 때는 라우팅 모드를 주의하세요. 라우팅 모드를 'LAN 및 중국 본토 우회'로 두면 중국 본토 사이트 접속은 원래 프록시를 거치지 않으므로 출구 IP가 그대로인 것이 정상입니다. 확인은 해외 사이트나 해외 IP 조회 페이지로 해야 합니다. 라우팅 모드는 '설정' → '라우팅 모드'에서 전환합니다.
대상 사이트 확인은 마지막에 합니다. 출구 IP는 바뀌었는데 대상 사이트가 열리지 않는다면 보통 DNS 해석이나 분기 문제입니다. 먼저 '설정' → '앱별 프록시'에서 브라우저가 제외되어 있지 않은지 확인하고, 다음으로 '도메인 해석 전략'이 현재 네트워크와 충돌하지 않는지 보세요.
노드 파라미터 확인: 프로토콜과 전송 필드
구독으로 가져온 노드 파라미터는 서버에서 내려주므로 보통 직접 수정할 필요가 없습니다. 실패한 노드를 살필 때는 노드 편집 화면을 열어 내려받은 필드와 대조해 구독이 잘못 해석되지 않았는지 확인할 수 있습니다.
VLESS + Reality
- 전송
- TCP
- Flow
- xtls-rprx-vision
- 지문
- chrome
- 공개 키와 짧은 ID
- 구독에서 내려받음
구독 가져오기 시 자동으로 채워지며, 어떤 필드든 직접 수정하면 핸드셰이크가 실패합니다.
VMess + WebSocket + TLS
- 전송
- WebSocket
- 경로
- /ws
- 암호화
- auto
- Host와 SNI
- 인증서 도메인과 일치
CDN을 거쳐 중계할 때는 Host와 SNI가 인증서 도메인과 일치해야 합니다.
필드가 구독과 다를 때, 예를 들어 경로나 SNI를 직접 수정했다면 실제 연결이 곧바로 실패합니다. 이때는 해당 노드를 삭제하고 구독을 다시 업데이트해 파라미터를 서버가 내려준 값으로 되돌리세요. 항목별로 추측하지 마세요.
파라미터를 직접 입력해야 하는 경우는 한 가지뿐입니다. 서버가 구독 없이 공유 링크만 제공할 때입니다. 이때는 '클립보드에서 가져오기'로 공유 링크 전체를 붙여 넣으면 클라이언트가 필드를 해석합니다.
첫 연결에서 자주 나오는 문제
아래 문제들은 첫 연결 단계에서 가장 자주 발생하며, 해결 방향은 모두 같습니다. 어느 계층이 뚫리지 않았는지 먼저 파악하고 나서 설정을 건드리세요.
실제 연결 테스트가 전부 시간 초과로 나오면?
먼저 이 기기의 네트워크로 웹페이지가 정상적으로 열리는지 확인하고, 구독이 유효 기간 내에 있는지 점검하세요. 특정 그룹만 전부 시간 초과라면 다른 그룹으로 테스트하고, 필요하면 다른 네트워크로 바꿔 구독을 다시 업데이트하세요.
속도 테스트 지연은 낮은데 웹페이지가 열리지 않으면?
실제 연결 통과는 핸드셰이크와 탐지 요청이 성공했다는 뜻일 뿐입니다. '설정' → '앱별 프록시'에서 브라우저가 제외되어 있지 않은지, 라우팅 모드가 대상 도메인을 직결로 보내고 있지 않은지 확인하세요.
연결 후 출구 IP가 바뀌지 않으면?
먼저 알림창의 연결 상태가 정상인지 확인하세요. 라우팅 모드가 'LAN 및 중국 본토 우회'일 때 중국 본토 사이트 접속이 프록시를 거치지 않는 것은 정상이므로, 해외 사이트나 해외 IP 조회 페이지로 다시 확인하세요.
노드를 바꿀 때마다 속도 테스트를 다시 해야 하나요?
구독을 업데이트하면 노드 항목이 초기화되므로 일괄 테스트를 다시 하는 편이 좋습니다. 일상적으로 노드를 바꿀 때는 이미 테스트한 항목을 선택하기만 하면 되고 반복 측정은 필요 없습니다.
일반 지연과 실제 연결 지연 차이가 크게 나도 정상인가요?
정상입니다. CDN을 거치는 노드는 일반 지연이 엣지 노드까지만 측정되고, 실제 연결은 원본 회선까지 통과해야 하므로 두 값이 수십 밀리초 차이 나는 일이 흔합니다.