V2Ray 속도 느릴 때 해결 방법: 노드·회선·로컬 설정별 점검

1. 첫 접속 지연·지속적인 저속·연결 실패 구분하기

지연 시간이 짧다고 다운로드가 빠른 것은 아닙니다. 노드 목록의 지연 테스트는 특정 방식으로 측정한 응답 시간일 뿐, 사용 가능한 대역폭을 보여 주지 않습니다. 다운로드 속도에는 서버 부하, 통신사 경로, 대상 사이트의 속도 제한, 로컬 네트워크가 모두 영향을 줍니다. 먼저 어느 단계에서 느려지는지 확인한 다음 설정을 조정하세요.

v2rayN은 클라이언트 관리 인터페이스이며, 실제 연결 처리는 선택한 코어가 담당합니다. Project V, V2Fly, Xray는 관련 프로젝트 배경을 설명하는 이름이지 성능 등급이 아닙니다. VMess, VLESS 같은 프로토콜도 속도 등급이 아닙니다. 대개 프로토콜 이름보다 노드 위치, 전송 방식 조합, 서버 자원이 속도 차이를 더 잘 설명합니다.

2. 재현 가능한 로컬 테스트 기준 만들기

노드, 대상 주소, 접속 네트워크, 프록시 연결 방식을 고정하세요. 아래 예시는 Windows의 v2rayN에서 혼합 프록시 포트 127.0.0.1:10808을 사용하는 경우입니다. 10808은 예시이므로 실행 전에 실제 설정과 코어 시작 로그에서 포트를 확인하세요. 오래된 안내에 나오는 10809를 그대로 사용하지 마세요.

1. 환경 기록

   「도움말」→「정보」에서 클라이언트 버전 전체를 기록하고, 시작 로그에서 코어 이름과 버전도 확인하세요. 현재 노드, 라우팅 모드, TUN 사용 여부를 기록한 뒤에는 테스트 중 업그레이드와 규칙 변경을 동시에 하지 마세요.

2. 프록시 연결 방식 확인

   「설정」→「매개변수 설정」에서 로컬 수신 포트를 확인하세요. 메뉴 구성은 버전에 따라 달라질 수 있으므로 시작 로그를 기준으로 삼으세요. 두 연결 방식을 혼용하지 않도록 우선 TUN을 끄고 명시적 HTTP 프록시로 기준값을 측정하세요.

3. 테스트 조건 고정

   구독 목록 일괄 속도 측정, 클라우드 드라이브 동기화, 다른 다운로드를 중지하세요. 안정적으로 접속되는 HTTPS 주소를 하나 고르고, 같은 노드를 유지한 채 아래 명령을 연속 3회 실행하세요. 가장 좋은 값이 아니라 가운데 값을 기준으로 삼습니다.

4. 결과 저장

   테스트 시각, 대상 주소, 연결 시간, 첫 바이트까지 걸린 시간, 오류 메시지 원문을 기록하세요. 설정을 하나 바꾼 뒤 다시 3회 측정하고, 개선이 꾸준하지 않으면 원래 값으로 되돌리세요. 기준값에서 설정이 점점 벗어나는 것을 방지할 수 있습니다.

curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 30 -o NUL -sS -w "connect=%{time_connect}s tls=%{time_appconnect}s first=%{time_starttransfer}s total=%{time_total}s\n" https://example.com/

여기서 example.com은 명령 실행 시간을 보여 주기 위한 예시일 뿐, 최대 대역폭 측정에는 적합하지 않습니다. 로컬 HTTP 프록시를 통해 HTTPS에 접속할 때 time_connect는 주로 로컬 프록시까지 연결하는 시간을 나타내며, 원격 노드까지의 지연 시간으로 볼 수 없습니다. TLS 및 첫 바이트 시간에는 프록시 경로와 대상 사이트의 처리 시간도 포함됩니다. 전송량을 측정하려면 접근 권한이 있는 고정된 대용량 파일을 사용하고, 응답이 오류 페이지가 아닌지 확인하세요.

3. 노드 부하와 해외 회선: 교차 테스트로 원인 찾기

한 번의 속도 측정만으로는 노드가 혼잡한지 경로가 막히는지 구분하기 어렵습니다. 가장 유용한 비교는 ‘같은 네트워크에서 노드 변경’과 ‘같은 노드에서 네트워크 변경’입니다. 테스트 대상은 그대로 유지하고 가능한 한 가까운 시간에 측정해 대상 사이트 자체의 부하 변화를 배제하세요.

예를 들어 다음과 같이 기록할 수 있습니다. 같은 파일을 노드 A에서 다운로드했을 때 낮에는 8 MB/s, 저녁에는 0.8 MB/s였고, 같은 시간 노드 B는 6 MB/s를 유지했습니다. 이 데이터로 문제 범위를 노드 A의 자원 또는 경로로 좁힐 수는 있지만, 서버 CPU가 포화 상태라고 단정할 수는 없습니다. 서버 부하를 확인하려면 서버 측 CPU, 대역폭, 연결 수, 속도 제한 정보를 확인해야 합니다. 수치는 판독 방법을 보여 주는 예시이며 이 사이트에서 직접 측정한 값이 아닙니다.

• 노드가 지리적으로 가까워도 통신사 간 연결이나 우회 경로 때문에 실제 경로가 짧다고 볼 수는 없습니다.
• 일반 ping에서 패킷 손실이 나타나도 ICMP 속도 제한 때문일 수 있습니다. 앱 연결, 지속 전송, 재시도 현상도 함께 확인하세요.
• 같은 진입점이나 출구를 공유하는 두 노드는 완전히 독립적인 비교 대상이 아닙니다. 필요하면 서로 다른 회선 그룹을 선택해 비교하세요.
• 먼저 다중 연결 다운로드를 켜서 속도를 ‘보충’하지 마세요. 동시 연결은 연결 및 대역폭 경쟁을 키우고 단일 연결의 패킷 손실을 가릴 수 있습니다.

4. DNS와 라우팅: 요청이 실제로 향하는 경로 확인

DNS는 주로 이름 조회 대기 시간, 대상 IP 선택, IP 기반 규칙 매칭에 영향을 줍니다. 노드 대역폭을 늘려 주지는 않습니다. 노드 도메인을 누가 조회하는지, 대상 도메인을 누가 조회하는지, 라우팅 규칙 적용을 위해 조회가 발생하는지를 구분해야 합니다. 브라우저의 보안 DNS 설정은 시스템이나 코어의 DNS 경로와 다를 수도 있습니다.

• 노드 주소 조회 실패: 프록시 연결이 성립되기 전에도 노드 도메인 조회가 필요합니다. 아직 연결되지 않은 프록시에 이 과정을 전적으로 의존할 수는 없습니다.
• 대상 도메인 조회 지연: 첫 방문에서만 느린지 확인하세요. 사이트를 계속 바꾸기보다 같은 대상에 처음 요청했을 때와 다시 요청했을 때를 비교합니다.
• 출구와 맞지 않는 조회 결과: 일부 CDN은 DNS 조회 위치에 따라 주소를 할당합니다. 원격 출구 위치와 대상 IP 위치가 맞지 않으면 우회 경로를 거칠 수 있습니다.
• 라우팅 규칙이 예상과 다르게 적용됨: 로그에 표시된 대상과 아웃바운드 태그를 확인해 요청이 의도치 않게 직접 연결되거나 로컬 서비스가 원격 경로를 거치지 않는지 살펴보세요.

아래는 규칙 순서를 설명하기 위한 V2Ray/Xray 스타일의 routing 조각이며, 완전한 설정 파일은 아닙니다. 먼저 사설 주소를 direct로 보내고 나머지 TCP 및 UDP 요청은 proxy로 전달합니다. 사용 전에 같은 이름의 아웃바운드가 이미 있는지, geoip 데이터가 준비되어 있는지 확인하세요. v2rayN에서는 먼저 백업해 인터페이스가 생성한 규칙과 중복 적용되지 않도록 하세요.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

AsIs는 라우팅 단계에서 규칙 매칭을 위해 도메인을 IP로 능동적으로 조회하지 않는다는 뜻입니다. 따라서 도메인 요청은 IP 조건에 일치하지 않을 수 있지만, 실제 연결 과정에서 조회가 필요할 수 있습니다. 이를 ‘DNS 끄기’로 해석하지 마세요. IPIfNonMatch와 IPOnDemand는 조회를 유발하는 방식이 다르므로 실제 코어와 규칙을 함께 확인해야 합니다. 필드 전체 설명은 JSON 설정 핸드북에서 확인하세요.

5. 스니핑과 MTU: 증상과 맞을 때만 조정

스니핑은 트래픽에서 도메인이나 프로토콜을 식별해 라우팅을 돕는 기능이지, 범용 속도 향상 옵션이 아닙니다. 켜면 도메인 규칙의 적용 결과가 달라질 수 있고, 끄면 도메인 기반 분기가 작동하지 않을 수도 있습니다. 같은 노드와 대상을 유지해 비교하고 아웃바운드 변경도 함께 확인하세요. 웹페이지가 우연히 한 번 빨라졌다는 이유만으로 판단하지 마세요.

MTU는 인터페이스가 허용하는 최대 전송 단위입니다. 경로 MTU 탐색이 막히면 핸드셰이크는 성공하지만 큰 데이터를 전송할 때 멈출 수 있습니다. TUN 모드에서만 재현된다면 실제로 TUN MTU 항목을 제공하는 설정 또는 구성에서 1500을 1400으로 임시 변경한 뒤 1380과 비교하세요. 이는 문제 해결을 위해 시험해 볼 값일 뿐 최적값을 보장하지 않습니다. 테스트 목적으로 모든 물리 네트워크 어댑터를 변경하지 마세요.

6. 실제 로그로 오류 구분하기: 모든 문제를 저속으로 보지 않기

오류가 발생한 시각을 먼저 기록한 다음 해당 연결의 대상, 아웃바운드, 앞뒤 로그를 확인하세요. 코어에 따라 로그 접두어나 주변 문맥이 달라질 수 있으며, 아래는 흔히 볼 수 있는 오류 문구입니다. 오류만으로 책임 소재를 단정하지 말고 발생한 위치를 확인하세요. 로그 수준을 임시로 높였다면 한 번 재현한 뒤 평소 수준으로 되돌려 디스크 기록이 관찰에 영향을 주지 않도록 하세요.

7. 자주 묻는 질문과 점검을 마칠 때

같은 대상을 연속 3회 테스트했을 때 허용 가능한 속도로 회복되고 평소 사용 중 연결이 끊기지 않는다면 ‘최적화 설정’을 더 추가하지 말고 멈추세요. 문제가 계속되면 클라이언트와 코어 버전, 시간대, 노드 그룹, 접속 네트워크, 첫 바이트 시간, 오류 문구를 정리하세요. 로그를 공유하기 전에 구독 링크, 인증 정보, 개인 접속 기록을 삭제하세요. 문제를 재현할 수 있을 만큼 설명하되 연결 자격 증명은 노출하지 마세요.

• 노드 측으로 범위 좁힘: 같은 네트워크에서 특정 노드만 문제가 있다면 서버 자원과 경로를 확인하세요.
• 회선 측으로 범위 좁힘: 같은 노드가 다른 접속 네트워크에서 정상이라면 시간대와 통신사별 비교 데이터를 보관하세요.
• 로컬 측으로 범위 좁힘: 명시적 프록시는 정상이지만 특정 앱이나 TUN에서 문제가 있다면 해당 연결 방식을 점검하세요.
• 원인 미확정: 기준 설정으로 되돌리고 별도 대상과 두 번째 접속 네트워크를 추가하세요. DNS, MTU, 라우팅을 한꺼번에 변경하지 마세요.