V2Ray TLS 핸드셰이크 실패·인증서 오류 해결: 시스템 시간과 SNI 설정 점검

1. 연결 과정 중 어느 단계에서 오류가 나는지 확인

v2rayN은 데스크톱 클라이언트 인터페이스이며, 실제 연결을 설정하고 TLS 오류를 기록하는 것은 실행된 프록시 코어입니다. v2rayNG는 Xray 코어를, v2flyNG는 V2Fly 코어를 사용합니다. 코어와 버전에 따라 로그 문구는 다를 수 있지만 점검 순서는 대체로 같습니다. 먼저 구독 다운로드, 노드의 아웃바운드 연결, 브라우저에서 접속한 웹사이트 중 어디에서 실패했는지 확인하세요.

‘구독 업데이트’ 중 인증서 오류가 표시되면 먼저 구독 주소의 HTTPS 서비스를 확인하세요. 이때 특정 노드의 SNI를 바꿔도 대개 해결되지 않습니다. 브라우저에서만 웹사이트 인증서 오류가 표시되고 코어 로그에 노드 아웃바운드 연결 성공이 기록된다면 대상 웹사이트, 로컬 HTTPS 검사 프로그램 또는 네트워크 로그인 페이지를 확인하세요. 노드 인증서 문제라고 단정할 수는 없습니다.

• 전체 상황을 함께 기록하세요: 오류 발생 시각, 현재 노드, 코어 이름, 오류 전후의 로그 몇 줄을 기록하세요. 공유할 때는 구독 주소, 사용자 식별 정보, 인증 정보를 가리세요.
• 요청은 한 번만 보내세요: 자동 속도 측정과 다른 네트워크 프로그램을 잠시 중지하고 노드 하나를 선택한 다음 일반 HTTPS 페이지에 접속하세요. 여러 오류가 뒤섞이는 것을 막을 수 있습니다.
• 가장 안쪽의 오류부터 확인하세요: failed to process outbound traffic는 바깥쪽의 포괄적인 메시지일 뿐입니다. 다음에 표시되는 x509, timeout, connection refused가 다음 점검 방향을 결정합니다.

2. 로그의 오류 키워드에 따라 점검 방향 선택

로그와 그대로 비교할 수 있도록 자주 나타나는 영어 오류 문구를 유지했습니다. 도메인, 날짜, 주소는 환경에 따라 달라지므로 로그 한 줄 전체가 똑같을 필요는 없습니다. 한 번에 한 가지 설정만 바꾸고 저장한 뒤 다시 연결해 가장 안쪽의 오류가 바뀌었는지 확인하세요.

EOF와 connection reset by peer만으로 SNI 오류라고 단정할 수는 없습니다. 연결이 종료되거나 초기화되었다는 뜻이므로 서버 접속 로그, 포트 연결 상태, 같은 노드를 다른 네트워크에서 사용한 결과를 함께 확인해 원인을 좁히세요.

3. 시스템 시간 차이: 먼저 동기화한 뒤 인증서 유효 기간 확인

TLS는 기기의 실제 시스템 시간을 기준으로 인증서가 유효 기간 안에 있는지 확인합니다. 인증서 발급일보다 시간이 이르거나 만료일을 지난 경우 검증이 실패합니다. 표시된 시간대가 잘못되었다고 해서 시스템 타임스탬프까지 잘못된 것은 아닙니다. 자동 동기화 결과와 실제 날짜를 확인하고, 시간대를 다른 지역으로 바꾸는 데 그치지 마세요.

1. 시간 설정 열기

   Windows 11에서는 ‘설정’ → ‘시간 및 언어’ → ‘날짜 및 시간’으로 이동해 연도, 날짜, 시간을 확인하세요. 다른 데스크톱 운영체제에서는 시스템 설정의 날짜 및 시간 화면을 여세요.

2. 자동 동기화 실행

   ‘시간 자동 설정’을 켜고 ‘추가 설정’에서 ‘지금 동기화’를 누르세요. 동기화에 실패하면 먼저 네트워크와 시간 서비스에 연결할 수 있는지 확인하세요. 시간을 수동으로 계속 바꾸며 시험하지 마세요.

3. 안드로이드 시간 확인

   안드로이드에서 ‘설정’을 열고 ‘날짜 및 시간’을 검색한 뒤 ‘시간 자동 설정’과 자동 시간대 옵션을 켜세요. 상위 메뉴 이름은 기기에 따라 ‘시스템’ 또는 ‘추가 설정’일 수 있으므로 설정 검색 결과를 기준으로 확인하세요.

4. 연결 다시 설정

   클라이언트 연결을 중지했다가 다시 시작하고 한 번 더 접속해 보세요. 유효 기간 오류가 계속되면 로그의 현재 시간과 인증서 시작일·만료일을 비교해 서버에서 인증서를 갱신해야 하는지 확인하세요.

기기를 끌 때마다 날짜가 몇 년 전으로 돌아간다면 하드웨어 시계, 배터리 또는 시스템 시간 서비스를 확인하세요. 기기 시간은 정상인데 여러 기기에서 같은 노드의 인증서 만료 오류가 발생한다면 각 기기의 보안 옵션을 바꾸기보다 서버 인증서를 확인하는 것이 좋습니다.

4. SNI, 노드 주소, Host: 세 항목을 각각 확인

노드 주소는 연결할 호스트를 지정합니다. SNI는 TLS 핸드셰이크에서 전송하는 서버 이름으로, 서버는 이를 바탕으로 사이트와 인증서를 선택할 수 있습니다. 일반 TLS 설정의 serverName은 보통 인증서 이름 검증에도 사용됩니다. WebSocket의 Host는 HTTP 요청 헤더에 속하며 다른 계층에서 작동합니다. 세 항목이 모두 도메인처럼 보인다고 해서 반드시 같은 값이어야 하는 것은 아닙니다.

v2rayN 메인 화면에서 해당 노드를 더블 클릭해 편집 창을 여세요. TLS 영역에서 ‘SNI’ 또는 ‘ServerName’ 항목을 찾아 서비스 제공자가 안내한 값과 비교합니다. 버전에 따라 항목 이름이 조금 다를 수 있습니다. v2rayNG와 v2flyNG에서는 노드 편집 메뉴에서 해당 TLS 매개변수를 확인하세요. 먼저 기존 값을 기록하고 주소, 포트, SNI, 전송 방식은 한꺼번에 바꾸지 마세요.

• SNI에는 호스트 이름만 입력하세요: 예를 들어 edge.example.net처럼 입력하고 https://, 포트, 경로는 포함하지 않습니다. 이 예시는 설명용으로 예약된 도메인입니다. 실제로는 서버가 안내한 이름을 입력해야 합니다.
• 주소와 SNI는 달라도 됩니다: 연결 주소로 IP를 사용한다고 해서 인증서가 해당 IP용이어야 하는 것은 아닙니다. 서버에서 도메인 인증서를 제공한다면 설정에 지정된 서버 이름을 입력하세요.
• SAN을 기준으로 확인하세요: 인증서 이름은 일반적으로 Subject Alternative Name으로 검증합니다. 와일드카드 이름 *.example.net은 보통 a.example.net과 일치하지만, 루트 도메인이나 여러 단계의 하위 도메인까지 포함한다고 볼 수는 없습니다.
• ‘위장 도메인’을 임의로 입력하면 안 됩니다: 이 표현은 SNI를 뜻할 수도 있고 HTTP Host를 뜻할 수도 있습니다. 먼저 어떤 항목을 가리키는지 확인하고, 접속되는 웹사이트의 도메인을 임의로 넣지 마세요.

5. allowInsecure와 인증서 체인: 검증을 복구하고 오류를 우회하지 마세요

allowInsecure는 코어 TLS 설정에서 인증서 검증을 건너뛸 때 사용하는 옵션입니다. 이 옵션을 켜면 도메인 불일치, 인증서 만료, 신뢰 체인 오류가 당장은 연결을 막지 않을 수 있지만, 연결 성공이 상대 서버의 신원을 보장하지는 않습니다. 일반 공용 TLS 노드에서는 인증서 검증을 켜 둔 상태로 실제 인증서 문제를 해결하세요.

• 클라이언트 측: 노드의 TLS 설정에서 ‘인증서 검증 건너뛰기’가 꺼져 있는지 확인하세요. 해당 설정은 보통 allowInsecure: false입니다. 구독을 사용한다면 다시 업데이트한 뒤 구독 내용이 이 값을 덮어쓰지 않았는지도 확인하세요.
• 서버 측: 실제로 완전한 인증서 체인을 불러왔는지 확인하세요. 일반적으로 서버는 리프 인증서와 필요한 중간 인증서를 제공해야 하며 사이트 인증서 한 장만으로는 부족합니다. 보통 서버가 전송하는 체인에 루트 인증서를 포함할 필요는 없습니다.
• 갱신 후: TLS 연결을 실제로 종료하는 구성 요소를 확인하세요. 리버스 프록시일 수도 있고 프록시 코어 자체일 수도 있습니다. 해당 구성 요소가 새 인증서를 다시 불러오도록 해야 합니다. 디스크의 파일만 갱신되었다고 적용이 끝난 것은 아닙니다.
• 사설 인증서: 발급자와 배포 정책을 확인한 뒤 시스템 또는 코어가 지원하는 방식으로 신뢰할 인증서를 설정하세요. 출처를 알 수 없는 루트 인증서를 모르는 노드에 가져오지 마세요.

같은 노드에서 오래된 기기 한 대만 unknown authority 오류가 나고 새 기기에서는 정상이라면 오래된 기기의 시스템 업데이트와 인증서 저장소를 확인하세요. 다만 서버에서 중간 인증서가 빠졌거나 다른 기기에 해당 인증서가 캐시되어 있을 가능성도 살펴봐야 합니다. 보안 프로그램의 HTTPS 검사로 발급자가 달라질 수도 있으므로 모든 보호 기능을 끄기보다 조직의 보안 정책에 따라 확인하세요.

6. 명령어로 포트 연결 문제와 TLS 설정 오류 구분

아래 명령은 권한이 있는 일반 TLS 서비스를 점검할 때만 사용하세요. 예시 도메인은 실제 노드 주소와 SNI로 바꾸고 포트도 노드의 실제 값으로 입력해야 합니다. 이 명령은 프록시 프로토콜의 연결 상태를 검사하지 않습니다. Windows PowerShell에서는 먼저 TCP 포트를 확인할 수 있으며, OpenSSL이 설치된 환경에서는 핸드셰이크와 인증서 검증 결과도 확인할 수 있습니다.

# PowerShell: 노드 TCP 포트에 연결할 수 있는지 확인
Test-NetConnection -ComputerName node.example.net -Port 443

# OpenSSL: 노드 주소에 연결하고 지정된 서버 이름을 전송해 검증
openssl s_client -connect node.example.net:443 -servername edge.example.net -verify_hostname edge.example.net -verify_return_error -showcerts

TcpTestSucceeded: True는 TCP 연결이 성공했다는 뜻일 뿐, 인증서가 신뢰할 수 있거나 프록시 인증 및 라우팅이 정상이라는 뜻은 아닙니다. OpenSSL의 -servername은 SNI를 전송하고 -verify_hostname은 검증할 이름을 지정합니다. 두 옵션의 역할은 다르므로 앞의 옵션만 추가해서는 이름 검증을 완전히 대신할 수 없습니다.

1. TCP 연결에 실패하면 주소, 포트, 서버 수신 상태, 방화벽부터 확인하세요. 인증서 이름을 계속 바꿔도 해결되지 않습니다.
2. TCP 연결은 성공했지만 TLS가 아닌 데이터가 반환되면 포트 매핑과 리버스 프록시 진입점이 올바른지 확인하세요.
3. TLS에서 이름 또는 신뢰 체인 오류가 발생하면 인증서 SAN, 완전한 체인, 기기의 인증서 저장소를 확인하세요.
4. TLS 검증은 통과했는데 클라이언트 연결이 계속 실패하면 프록시 프로토콜, 인증 매개변수, WebSocket 경로 등 다른 전송 설정을 확인하세요.

7. 수정 후 재검사 및 자주 묻는 질문

재검사할 때는 같은 노드, 같은 네트워크, 같은 대상 페이지를 유지하고 자동 전환을 끈 다음 연결을 다시 시작하세요. 새 로그에 기존 인증서 오류가 더 이상 나타나지 않는지 확인한 뒤 평소의 라우팅 설정을 복구합니다. 서비스 제공자의 도움이 필요하면 오류 발생 시각, 오류 키워드, 사용한 코어, 완료한 점검 항목을 전달하세요. 구독 링크 전체를 보내지 마세요.

최종 점검 순서는 연결 지점, 시스템 시간, SNI와 인증서의 일치 여부, 인증서 체인의 신뢰성, 프록시 매개변수입니다. DNS, 포트, 도메인, 보안 옵션을 한꺼번에 바꾸기보다 이 순서대로 결과를 기록하면 원인을 더 쉽게 찾을 수 있습니다. 항목의 의미는 용어집에서 확인하고, 노드를 처음 가져온다면 클라이언트 설정 가이드를 참고하세요.