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

먼저 로그 확인: TLS 핸드셰이크 실패 단계 찾기

연결 단계: 노드에 시간 초과가 표시된다고 인증서 오류인 것은 아닙니다. 일반적인 TCP + TLS 프록시 연결은 서버 주소 확인, TCP 연결, TLS 협상, 프록시 프로토콜 인증 및 데이터 전송 순으로 진행됩니다. 앞 단계 중 하나라도 실패하면 화면에는 연결할 수 없는 것으로 표시될 수 있습니다.

로그 확인: 클라이언트 로그에서 방금 연결할 때 발생한 오류를 찾아 시간, 오류 원문, 사용한 코어 이름을 기록하세요. 바깥쪽의 failed to process outbound traffic만 보지 말고 근본 원인을 확인해야 합니다. 이 메시지는 대개 오류를 감싸는 표현일 뿐이라 인증서, 네트워크, 프로토콜 설정 중 무엇이 문제인지 단독으로 판단할 수 없습니다.

시간 초과 구분: 로그에 dial tcp, i/o timeout 또는 연결 거부만 있고 인증서 오류가 없다면 주소, 포트, 서버 리스닝 상태부터 확인하세요. 서버 인증서를 받기 전이라면 인증서 검증 설정을 바꿔도 연결 문제는 해결되지 않습니다.

시스템 시간 동기화 문제: 날짜와 동기화 상태 확인

유효 기간 확인: 인증서에는 시작 시각과 만료 시각이 있으며, 클라이언트는 기기의 시계를 기준으로 유효성을 판단합니다. 컴퓨터를 오랫동안 끄거나, 가상 머신 스냅샷을 복원하거나, 기기 전원 차단 후 시간이 초기화되면 정상 인증서도 아직 유효하지 않거나 이미 만료된 것으로 보일 수 있습니다. 작업 표시줄의 시·분만 보지 말고 연도와 날짜도 확인하세요.

1. Windows 시간 동기화: 「설정」→「시간 및 언어」→「날짜 및 시간」을 열고 「자동으로 시간 설정」을 켜세요. 시간대를 확인한 뒤 「지금 동기화」를 누릅니다. 버튼 위치는 Windows 버전에 따라 다를 수 있습니다.
2. 동기화 결과 확인: 최근 동기화가 성공한 시각을 확인하세요. 자세한 상태를 확인하려면 명령 프롬프트에서 아래의 읽기 전용 명령을 실행해 시간 원본과 동기화 상태를 확인합니다.
3. Android 시간 동기화: 시스템 설정에서 「날짜 및 시간」을 검색하고 자동 날짜 및 시간과 자동 시간대를 켜세요. 메뉴 경로는 기기 시스템에 따라 다를 수 있습니다. 설정을 마친 뒤 다시 연결해 보세요.
4. 재현 확인: 시간을 맞춘 뒤 다시 연결하고 같은 노드의 새 로그를 확인하세요. 여전히 만료 오류가 표시되면 기기 날짜를 계속 바꾸지 말고 서버 관리자에게 인증서를 확인해 달라고 요청하세요.

w32tm /query /status
w32tm /query /source

시간대 차이: 시간대는 주로 현지 시간 표시 방식에 영향을 주며, TLS 검증은 절대 시간을 비교합니다. 시간대를 다른 지역으로 바꾸는 것은 인증서 문제의 해결책이 아닙니다. 다른 기기와 시계 표시를 맞추는 것이 아니라 시스템의 실제 시각을 정확하게 맞춰야 합니다.

SNI 설정 오류: 서버 주소, 인증서 도메인, Host를 각각 확인

필드별 역할: SNI는 클라이언트가 TLS 핸드셰이크에서 보내는 서버 이름으로, 같은 주소에서 서비스가 올바른 인증서와 사이트를 선택하도록 하는 데 자주 사용됩니다. Xray와 V2Ray의 일반적인 TLS 설정에서는 serverName으로 지정하며, 클라이언트 화면에는 SNI 또는 서버 이름으로 표시될 수 있습니다. 연결 주소는 IP일 수 있지만 인증서의 신원은 보통 서버에서 지정한 도메인으로 검증해야 합니다.

클라이언트 화면 확인: v2rayN에서 현재 노드를 편집해 주소, 포트, 전송 방식, TLS 설정을 확인하세요. v2rayNG와 v2flyNG에서는 해당 노드의 편집 화면에서 서버 이름 관련 필드를 확인합니다. 버전에 따라 화면 배치가 다를 수 있으므로 필드의 의미와 실제 생성된 코어 설정을 기준으로 판단하세요. 입력란의 위치만 보고 결정하지 마세요.

• 이름 형식: SNI에는 보통 호스트 이름만 입력합니다. https://, 포트, 경로, 끝부분의 공백은 포함하지 마세요.
• 인증서 이름 확인: 인증서 목록에 표시된 약칭만 보지 말고 주체 대체 이름(SAN)을 확인하세요. 와일드카드는 보통 한 단계 하위 도메인만 일치하며 루트 도메인까지 자동으로 포함하지 않습니다.
• 비워 둔 경우: 일부 설정은 서버 주소에서 이름을 유추합니다. IP 주소로 연결할 때는 특히 자동 추측에 의존하지 말고 서버 안내에 따라 명시적으로 확인하세요.
• 구독 업데이트 덮어쓰기: 직접 수정해도 다음 구독 업데이트 때 해당 필드가 덮어써질 수 있습니다. 가져온 설정이 계속 잘못된다면 같은 노드를 반복해서 수정하지 말고 구독 설정 제공처에 문의하세요.

인증서 체인과 서버: 브라우저에서 열려도 코어가 인증서를 통과하는 것은 아닙니다

신뢰 체인 확인: 서버는 일반적으로 사이트 인증서와 필요한 중간 인증서를 보내고, 클라이언트는 이를 신뢰하는 루트 인증서까지 연결합니다. 브라우저는 중간 인증서를 캐시하거나 다른 신뢰 체계를 사용할 수 있습니다. 따라서 브라우저에서 열린다는 사실은 참고 사항일 뿐, 프록시 코어의 검증 결과를 대신할 수 없습니다.

1. TLS 종료 지점 확인: TLS를 리버스 프록시, 로드 밸런서 엔드포인트, 프록시 코어 중 어디에서 처리하는지 확인하세요. 핸드셰이크를 실제로 처리하는 계층에 인증서를 갱신해야 합니다.
2. 전체 체인 확인: 서버에 전체 인증서 체인이 로드되어 있는지, 인증서와 개인 키가 서로 일치하는지 확인하세요. 인증서를 갱신한 뒤에는 디스크 파일만 바꾼 것이 아니라 설정을 다시 불러왔는지도 확인합니다.
3. 여러 엔드포인트 확인: 도메인에 여러 주소나 엔드포인트가 연결되어 있다면 각각 반환하는 인증서를 확인하세요. 일부 엔드포인트가 이전 인증서를 계속 사용하면 간헐적으로 연결이 실패할 수 있습니다.
4. 기기의 신뢰 설정 확인: 운영체제와 클라이언트를 지원 중인 버전으로 업데이트하고, 기업 네트워크에서 TLS 검사 기능을 사용하는지 확인하세요. 문제 해결을 위해 출처가 불분명한 루트 인증서를 함부로 설치하지 마세요.

allowInsecure 오용: 검증 우회는 인증서 문제 해결책이 아닙니다

설정의 의미: 일반적인 TLS 설정에서 allowInsecure: true는 보통 인증서 체인과 이름 검증을 건너뛰어 서버 신원을 보장하지 못하게 합니다. TCP 연결 실패, 잘못된 포트, 서버의 핸드셰이크 거부, 프록시 인증 실패는 해결하지 못하며 장기적인 연결 설정으로 사용해서도 안 됩니다.

{
  "security": "tls",
  "tlsSettings": {
    "allowInsecure": false
  }
}

설정 범위: 위 내용은 일반적인 streamSettings에서 TLS 검증 옵션만 보여 주며, 전체 노드 설정이 아닙니다. 실제 serverName, 전송 계층, 인증 매개변수도 포함되어 있지 않습니다. 이 내용을 기존 설정에 덮어쓰지 마세요. 현재 노드의 TLS 설정에서 「안전하지 않은 연결 허용」 또는 「인증서 검증 건너뛰기」가 켜져 있지 않은지 확인하세요.

• 오류가 사라졌다는 의미: 검증을 건너뛴 뒤 오류가 사라졌다면 인증서 검증과 관련된 문제일 가능성만 보여 줄 뿐, 올바른 서버에 연결되었다는 뜻은 아닙니다.
• 권장 해결 방법: 검증을 켠 상태로 유지하고 시스템 시간, SNI, 전체 인증서 체인 또는 서버 인증서를 바로잡은 뒤 다시 테스트하세요.
• 자체 서명 인증서 사용: 신뢰 설정 방식을 명확히 정하고 현재 코어에서 지원하는 인증서 신뢰 설정을 확인하세요. 검증을 끄는 방식으로 모든 문제를 대신 해결하려고 해서는 안 됩니다.

코어와 프로토콜 구분: 일반 TLS와 REALITY에 같은 설정을 적용하지 마세요

프로토콜 구분: VMess와 VLESS는 프록시 프로토콜이며 TLS 사용 여부는 전송 계층과 보안 계층 설정에 따라 달라집니다. VLESS라는 이유만으로 일반 TLS를 사용한다고 단정하지 마세요. 화면에 서버 이름 필드가 있다고 해서 모든 보안 계층의 문제를 인증서 만료로 처리해서도 안 됩니다.

REALITY 적용 범위: REALITY는 일반 TLS 인증서 배포와 다른 검증 방식을 사용하며, 서버 설정과 클라이언트 설정이 정확히 대응해야 합니다. 시스템 시간도 확인할 필요가 있지만 관련 오류가 발생하면 먼저 보안 계층 종류를 확인한 뒤 해당 코어의 요구 사항에 따라 매개변수를 점검하세요. 일반 웹사이트 인증서 교체만으로 모든 문제가 해결된다고 서버 관리자에게 요구해서는 안 됩니다.

최종 재검사: 매번 한 가지 항목만 수정하고 「원래 오류 → 수정 항목 → 새 로그」를 기록하세요. 시간, SNI, 인증서 체인, 서버, 보안 계층 호환성 순으로 범위를 좁힙니다. TLS 연결에 성공한 뒤에도 접속할 수 없다면 보안 설정을 계속 끄지 말고 프록시 인증, 라우팅 분기, DNS를 확인하세요.

1. 기준 상태 기록: 현재 필드와 원래 오류를 기록하고 구독 정보는 신뢰할 수 있는 위치에 보관하세요.
2. 항목별 검증: 한 항목을 수정할 때마다 다시 연결하고 로그가 이번 테스트에서 생성된 것인지 확인하세요.
3. 설정 복원: 임시 디버깅 변경 사항을 되돌리고 인증서 검증을 켠 상태로 유지하세요.
4. 변경 유지 여부 확인: 클라이언트를 다시 시작하세요. 구독을 사용한다면 다음 업데이트에서 수정 사항이 다시 덮어써지는지 확인하세요.