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

1. 인증서 오류와 핸드셰이크 시간 초과 구분하기

TLS 핸드셰이크는 프록시 프로토콜로 데이터를 주고받기 전에 진행됩니다. 클라이언트가 서버에 연결하고 핸드셰이크 정보를 보낸 다음 서버 신원을 확인해 암호화 연결을 협상합니다. 어느 단계에서든 실패하면 최종 로그에는 ‘연결 실패’로 표시될 수 있습니다. 따라서 마지막 줄만 보지 말고 앞부분에서 x509, tls 또는 구체적인 네트워크 오류가 포함된 원인 메시지를 찾아야 합니다.

v2rayN 메인 창 하단의 로그에서 연결 실패 시각과 노드 이름을 기록하세요. v2rayNG에서는 메인 화면 메뉴에서 ‘로그’를 열고 다시 연결한 뒤 새로 추가된 기록을 확인하면 됩니다. 버전에 따라 메뉴 이름은 다를 수 있지만, 확인할 내용은 같습니다. 같은 연결 시도에서 가장 구체적인 하위 오류를 찾으세요. ‘모든 재시도 실패’ 같은 요약 메시지만 반복해서 확인해서는 원인을 알기 어렵습니다.

2. 시스템 시간이 맞지 않을 때: 시간 동기화 후 다시 연결

인증서에는 유효 시작 시각과 만료 시각이 정해져 있습니다. 기기 날짜가 몇 달 전으로 어긋나면 ‘아직 유효하지 않음’ 오류가 발생할 수 있고, 미래로 어긋나면 ‘만료됨’으로 판단될 수 있습니다. TLS 검증은 실제 시각을 기준으로 합니다. 표시된 시간대가 다르다고 해서 시스템 시계가 반드시 잘못된 것은 아닙니다. 다만 시간대를 수동으로 바꾼 뒤 시각까지 직접 조정하면 실제 시간이 어긋날 수 있습니다.

1. Windows 11: ‘설정’ → ‘시간 및 언어’ → ‘날짜 및 시간’으로 이동해 ‘자동으로 시간 설정’을 켜고, 시간대를 확인한 다음 ‘지금 동기화’를 선택하세요. 동기화가 완료되면 연도, 날짜, 분 단위 시각을 확인합니다.
2. 동기화 상태 확인: 터미널에서 아래 조회 명령을 실행하고 시간 원본과 마지막으로 동기화에 성공한 시각을 확인하세요. 강제로 다시 동기화하려면 두 번째 명령을 관리자 권한으로 실행합니다.
3. Android: 시스템 ‘설정’ → ‘시스템’ → ‘날짜 및 시간’에서 ‘자동으로 시간 설정’과 자동 시간대를 켜세요. 기기에 따라 ‘추가 설정’에 메뉴가 있을 수 있습니다. 네트워크에 다시 연결한 뒤 시간이 갱신되었는지 확인합니다.
4. 재확인: 현재 노드 연결을 끊었다가 다시 연결하고 요청을 한 번 더 보내세요. 시간 동기화만으로 이미 실패한 연결이 자동 복구되지는 않으므로 새 로그를 확인해야 합니다.

w32tm /query /status
w32tm /resync

Windows에서 시간 서비스가 시작되지 않았다는 메시지가 표시되면 ‘서비스’에서 Windows Time 상태를 먼저 확인하세요. 조직에서 관리하는 PC라면 관리자가 설정한 시간 원본을 따라야 하며 임의로 바꾸지 마세요. 컴퓨터를 끌 때마다 날짜가 초기화된다면 기기 펌웨어 시계와 하드웨어 상태도 점검해야 합니다. 시간이 올바른데도 인증서 만료 오류가 계속되면 서버 측에서 인증서를 갱신하고 서비스를 다시 불러와야 합니다.

3. SNI와 serverName: 도메인을 확인하고 연결 IP를 그대로 쓰지 않기

SNI는 핸드셰이크 중 클라이언트가 서버에 전달하는 이름으로, 같은 주소를 공유하는 서버가 적절한 인증서와 사이트를 선택하도록 돕습니다. 일반적인 TLS 설정에서 tlsSettings.serverName은 보통 SNI 전송과 인증서 이름 검증에 함께 사용됩니다. 노드 연결 주소나 WebSocket의 HTTP Host와는 다른 항목입니다. 셋이 같을 수도 있지만, 서버 구성에 따라 서로 다른 값을 사용할 수 있습니다.

v2rayN에서는 대상 서버 행을 두 번 클릭해 노드 편집 창을 열고 TLS 관련 영역에서 ‘SNI’ 또는 ‘서버 이름’을 확인하세요. v2rayNG에서는 노드 편집 아이콘을 누른 뒤 TLS 영역의 해당 항목을 확인합니다. 버전과 노드 유형에 따라 항목 이름이 다를 수 있으므로 구독에서 제공한 설정을 기준으로 하세요. 연결 주소, 위장 도메인, SNI를 무조건 같은 문자열로 바꾸지 마세요.

• 도메인만 입력하세요. 예: edge.example.com. https://edge.example.com/처럼 입력하거나 :443을 덧붙이지 마세요.
• 노드는 IP로 연결하지만 인증서는 도메인용으로 발급된 경우에도 보통 제공자가 안내한 도메인을 입력해야 합니다. 해당 IP를 SNI로 그대로 사용하지 마세요.
• 와일드카드 인증서 *.example.com은 일반적으로 edge.example.com을 포함하지만, example.com이나 a.edge.example.com은 포함하지 않습니다.
• 구독을 업데이트하면 수동 변경 내용이 덮어써질 수 있습니다. 테스트를 위해 설정을 임시로 바꾸기 전 노드를 복제하고 용도를 분명히 표시해 다음 업데이트 후에도 점검 기록을 보존하세요.

아래는 일반 TCP + TLS의 streamSettings 일부만 보여주는 예시이며, 단독으로 실행할 수 있는 전체 설정이 아닙니다. 예시 도메인은 각 항목을 설명하기 위한 것으로 실제 설정에는 노드에서 제공한 값을 사용하세요. WebSocket 등 다른 전송 방식을 사용한다면 기존 전송 유형과 관련 설정을 유지해야 합니다.

{
  "streamSettings": {
    "network": "tcp",
    "security": "tls",
    "tlsSettings": {
      "serverName": "edge.example.com",
      "allowInsecure": false
    }
  }
}

4. allowInsecure와 인증서 체인: 서버 신원 검증 유지하기

allowInsecure는 ‘호환 모드’나 ‘속도 향상 옵션’이 아닙니다. 일반 TLS 설정에서 이 값을 true로 지정하면 중요한 인증서 검증을 건너뛰어 만료되었거나 이름이 맞지 않거나 신뢰할 수 없는 인증서도 정상적으로 차단되지 않습니다. 문제를 가릴 수는 있지만 예상한 서버에 연결되었다는 뜻은 아니며 네트워크 시간 초과도 해결하지 못합니다.

노드 편집 화면에서 ‘인증서 검증 건너뛰기’ 또는 ‘안전하지 않은 연결 허용’ 항목을 확인하세요. 일반적인 사용에서는 이 기능을 끄고 allowInsecure: false로 설정해야 합니다. 이전 설정에서 이 옵션을 켜 둔 상태였다면 검증을 복원한 뒤 발생한 인증서 오류를 확인하고 해결하세요. 장기적인 대책으로 다시 켜서는 안 됩니다.

• 이름 불일치: 먼저 SNI를 확인하세요. 값이 맞다면 서버가 기본 사이트 인증서를 불러오고 있을 수 있으므로 가상 호스트 설정을 점검해야 합니다.
• 알 수 없는 발급자: 서버가 중간 인증서를 포함한 전체 인증서 체인을 제공해야 합니다. 공개적으로 신뢰받는 인증서라면 일반적으로 사용자가 개인 루트 인증서를 추가로 가져올 필요가 없습니다.
• 오래된 기기 한 대에서만 실패: 시스템과 지원되는 클라이언트 버전을 업데이트하고 시스템 인증서 저장소를 확인하세요. 특정 노드 하나 때문에 출처가 불분명한 루트 인증서를 설치하지 마세요.
• 네트워크 변경 후 인증서가 달라짐: 공용 네트워크의 로그인 페이지, 기업용 프록시 또는 보안 프로그램의 HTTPS 검사 기능을 확인하세요. 필요하면 네트워크 관리자에게 확인을 요청합니다.

5. ALPN과 시간 초과: 서버의 전송 요구사항에 맞게 설정하기

ALPN은 TLS 핸드셰이크에서 애플리케이션 계층 프로토콜을 협상하는 기능으로, 흔히 사용하는 값은 h2와 http/1.1입니다. 노드 프로토콜 이름이 아니며 값을 많이 추가한다고 더 좋아지는 것도 아닙니다. HTTP/2 기반 gRPC 전송에는 HTTP/2 지원이 필요합니다. 기존 WebSocket Upgrade는 보통 HTTP/1.1을 사용하지만, 실제 설정은 서버와 리버스 프록시 구성에 따라 달라집니다.

1. 먼저 노드의 전송 유형을 확인한 다음 제공자의 안내에 따라 ALPN을 설정하세요. 별도 요구사항이 없다면 시험 삼아 프로토콜 하나만 지정하지 마세요.
2. 로그에 tls: no application protocol이 표시되면 클라이언트가 제시한 ALPN과 서버에서 허용하는 프로토콜이 일치하는지 확인하세요.
3. 로그에 시간 초과만 표시되면 먼저 실제 서버 포트를 확인하세요. 노드 포트가 8443이라면 443 테스트에 성공해도 해당 노드가 정상이라는 뜻은 아닙니다.
4. 노드 설정을 그대로 둔 채 현재 네트워크와 다른 사용 가능한 네트워크에서 각각 다시 테스트하세요. 결과가 다르면 네트워크 경로와 접속 제한부터 확인하는 것이 좋습니다.

Windows에서는 아래 명령으로 지정한 포트에 TCP 연결이 가능한지 테스트할 수 있습니다. 예시 도메인과 포트는 명령 형식만 보여주므로 노드의 실제 값으로 바꾸세요. TcpTestSucceeded: True는 TCP 연결이 성립했다는 뜻일 뿐, TLS 인증서나 ALPN 또는 프록시 인증이 올바르다는 의미는 아닙니다.

Test-NetConnection -ComputerName edge.example.com -Port 443

6. 자주 묻는 질문과 복구 후 확인

수정을 마친 뒤 노드에 다시 연결하고 실제 접속을 한 번 시도하세요. 새 로그에 인증서 검증 또는 핸드셰이크 오류가 없는지 확인한 다음 앱의 접속이 복구되었는지도 점검합니다. TLS가 완료되었는데도 접속할 수 없다면 프록시 인증, 전송 경로, 라우팅 설정을 추가로 확인하세요. 이미 올바른 것으로 확인한 SNI를 계속 바꾸지 마세요.

• 점검 기록 보관: 클라이언트 버전, 커널 버전, 실패 시각, 네트워크 환경과 구체적인 오류를 적어 두세요. ‘연결이 안 돼요’라고만 기록하지 마세요.
• 보안 설정 복원: 인증서 검증 건너뛰기가 꺼져 있는지 확인하고, 문제 해결을 위해 근거 없이 추가한 매개변수를 삭제하세요.
• 필요한 정보 전달: 노드 관리자에게 인증서 오류와 포트 상태를 알려주세요. 로그를 공유하기 전에는 구독 주소, 인증 정보, 개인 네트워크 주소를 가려야 합니다.