v2rayN, v2rayNG, v2flyNG 로그에 TLS, x509, 핸드셰이크 중단 오류가 나타날 때 참고하세요. 먼저 원래 오류 메시지를 확인해 연결 시간 초과와 인증서 검증 실패를 구분한 뒤 시스템 시간, 노드 주소와 SNI, 인증서 체인, 지문, 전송 설정을 차례로 점검합니다. 일반 TLS와 REALITY는 따로 확인해야 하며, 인증서 검증 건너뛰기는 설정 오류를 해결하는 방법이 아닙니다.
1. 로그부터 확인: 핸드셰이크 실패가 곧 인증서 오류는 아닙니다
TLS는 연결 수립과 프록시 프로토콜 통신 사이에서 동작합니다. 노드 주소 확인 실패, TCP 포트 연결 불가, 서버의 연결 종료도 클라이언트에는 최종적으로 “연결 실패”로 표시될 수 있습니다. 로그에 인증서 유효기간, 호스트 이름 또는 신뢰할 수 있는 인증 기관 관련 오류가 명시된 경우에 인증서를 우선 점검하세요. EOF 또는 context deadline exceeded 한 줄만으로는 원인을 판단하기 어렵습니다.
v2rayN 메인 화면의 로그 영역에서 연결을 한 번 재현하고 오류가 발생한 시각을 기록한 뒤, 같은 연결에서 앞서 발생한 내부 오류를 찾아보세요. Android 클라이언트에서는 메뉴의 ‘로그’에서 확인할 수 있습니다. 버전에 따라 로그 메뉴 위치는 다를 수 있지만, 속도 테스트 목록의 ‘실패’ 표시가 아니라 코어의 원본 로그를 확인해야 합니다. 로그를 공유하기 전에는 구독 주소, 사용자 식별 정보, 인증 정보를 가리세요.
오류: x509: certificate has expired or is not yet valid
원인 및 해결: 기기의 시간이 인증서 유효 기간과 맞지 않거나 서버 인증서가 실제로 만료된 경우입니다. 먼저 기기의 날짜와 시간을 동기화한 다음 인증서의 시작일과 만료일을 확인하세요.
오류: x509: certificate signed by unknown authority
원인 및 해결: 인증서 검증 체인을 신뢰할 수 있는 루트까지 연결하지 못한 상태입니다. 중간 인증서 누락, 자체 서명 인증서, 네트워크상의 인증서 대체 등이 원인일 수 있습니다. 서버가 전체 인증서 체인을 제공하는지와 기기의 신뢰 환경을 확인하고, 검증 기능을 바로 끄지는 마세요.
오류: tls: unrecognized name
원인 및 해결: 서버가 클라이언트에서 보낸 SNI 이름을 거부했을 수 있습니다. 노드에 설정된 서버 이름이 서버에서 허용하는 이름과 정확히 일치하는지, 잘못된 접속 지점에 연결한 것은 아닌지 확인하세요.
오류: remote error: tls: handshake failure
원인 및 해결: 상대편이 핸드셰이크를 중단한 상태입니다. TLS 설정, 클라이언트 인증서 요구 사항, 서버 접속 정책 등이 원인일 수 있습니다. 서버 로그와 노드 설정을 함께 확인해야 하며, 이 오류 한 줄만으로 인증서 만료를 단정할 수는 없습니다.
2. 시스템 시간 동기화: 날짜, 시간대, 인증서 유효기간
인증서 검증에서는 현재 시간과 인증서의 notBefore, notAfter를 비교합니다. 기기의 연도가 잘못되었거나 절전 모드에서 깨어난 뒤 시계가 크게 어긋나면 유효한 인증서도 아직 유효하지 않거나 만료된 것으로 판단될 수 있습니다. 시간대는 주로 표시 방식에 영향을 줍니다. 화면의 시간대 설정만 맞추고 끝내지 말고 시스템의 실제 시간이 정확한지 확인하세요.
-
컴퓨터 시간 동기화
Windows 11에서 ‘설정’ → ‘시간 및 언어’ → ‘날짜 및 시간’을 열고 ‘시간 자동 설정’을 켜세요. 동기화 영역에서 ‘지금 동기화’를 누른 다음 날짜, 연도, 시간대가 맞는지 확인하세요.
-
Android 시간 동기화
기본 Android의 ‘설정’ → ‘시스템’ → ‘날짜 및 시간’에서 시간과 시간대 자동 설정을 켜세요. 제조사별로 메뉴 위치가 다르면 설정에서 ‘날짜 및 시간’을 검색하고 네트워크 시간 동기화가 적용됐는지 확인하세요.
-
다시 연결하고 확인
연결을 끊었다가 노드에 다시 연결한 뒤 새 로그의 타임스탬프를 확인하세요. 만료 오류가 계속되면 원격 서버 인증서의 날짜를 확인하세요. 만료된 서버 인증서는 관리자가 갱신하고 다시 불러와야 합니다.
시간 동기화에 실패하면 기기가 정상적으로 인터넷에 연결되는지 먼저 확인하세요. 회사 네트워크에서는 시간 동기화 트래픽이 제한될 수 있습니다. 만료된 인증서에 맞추려고 시스템 날짜를 과거로 돌리지 마세요. 다른 HTTPS 연결에도 영향을 주고 서버 인증서 갱신 문제를 가릴 수 있습니다.
3. SNI 확인: 서버 주소, 인증서 이름, Host 구분하기
노드의 ‘주소’는 연결할 호스트나 IP를, ‘포트’는 연결할 서비스를 지정합니다. SNI는 TLS 핸드셰이크에서 전송하는 서버 이름입니다. 일반 TLS 설정에서 명시한 serverName은 보통 인증서의 호스트 이름 검증에도 사용됩니다. 연결 주소는 IP여도 되지만, 검증에 사용할 이름은 인증서에 포함된 도메인과 일치하고 서버 접속 정책에도 부합해야 합니다.
| 항목 | 용도 | 흔한 입력 오류 |
|---|---|---|
| 주소와 포트 | 원격 서버 접속 지점 지정 | HTTPS에서 흔히 쓰는 포트 443을 모든 노드의 포트로 입력 |
| SNI / serverName | TLS 가상 호스트 선택 및 일반 TLS 이름 검증에 사용 | https:// 접두사, 경로 또는 잘못된 하위 도메인 입력 |
| WebSocket Host | TLS 연결 후 HTTP 요청에 사용하는 호스트 필드 | Host를 바꾸면 인증서 이름 불일치가 해결된다고 착각 |
| WebSocket path | WebSocket 요청 경로 지정 | 앞에 슬래시를 빼먹거나 다른 노드의 경로 사용 |
| gRPC serviceName | gRPC 서비스 이름 지정 | 도메인 이름을 입력하거나 서버 이름과 다르게 입력 |
v2rayN 노드 목록에서 대상 노드를 더블 클릭해 편집 창을 열고 ‘주소’, ‘포트’, TLS 영역의 ‘SNI’ 또는 서버 이름 항목을 확인하세요. v2rayNG에서는 노드 오른쪽의 편집 아이콘을 눌러 TLS와 SNI 항목을 확인하면 됩니다. 버전에 따라 항목 이름이 다를 수 있으므로 해당 노드의 편집 화면을 기준으로 확인하고, 전역 라우팅 설정에서 SNI를 찾지는 마세요.
- SNI에는 보통
www.example.com처럼 도메인만 입력합니다. 프로토콜, 포트, 경로는 포함하지 마세요. 여기의 도메인은 형식 설명용이며 실제 값은 서버에서 안내한 이름을 사용해야 합니다. - 일반 인증서의 와일드카드
*.example.com은 보통a.example.com과 일치하지만, 루트 도메인이나 여러 단계의 하위 도메인까지 포함한다고 볼 수는 없습니다. - 서비스 제공자가 말하는 ‘위장 도메인’의 의미가 모호할 수 있습니다. TLS SNI, HTTP Host, REALITY 서버 이름 중 무엇을 뜻하는지 구체적으로 확인하세요. 이 세 항목은 서로 바꿔 쓸 수 없습니다.
로그에 특정 이름에 대해서는 인증서가 유효하지만 현재 이름에는 유효하지 않다고 명시되어 있다면, 잘못된 IP에 연결했는지 또는 접속 지점에서 기본 사이트 인증서를 반환하는지 먼저 확인한 뒤 SNI를 수정하세요. 유명 웹사이트 도메인을 임의로 넣으면 이름 불일치가 새로 발생할 가능성이 큽니다.
4. 인증서 체인, 지문, REALITY 설정 확인
루트 인증서를 신뢰한다고 해서 서버가 보내는 인증서 체인이 반드시 완전한 것은 아닙니다. 일반 TLS 서버는 리프 인증서와 필요한 중간 인증서를 제공해야 합니다. 일부 브라우저는 캐시된 정보로 중간 인증서를 보완할 수 있으므로 브라우저에서 열린다는 사실만으로 프록시 코어가 같은 체인을 검증할 수 있다고 볼 수는 없습니다. 테스트할 때 주소, 포트, SNI가 같은지, 도메인의 다른 접속 지점에 연결된 것은 아닌지도 확인하세요.
- 인증서 체인 오류: 서버 관리자가 전체 체인 파일과 갱신 후 인증서가 다시 로드됐는지 확인해야 합니다. 기기의 신뢰 저장소가 오래된 경우 시스템과 클라이언트를 업데이트한 뒤 다시 테스트하세요.
- 지문 불일치: uTLS를 지원하는 코어에서는
fingerprint로 ClientHello 특성을 선택할 수 있습니다. 이는 인증서 지문도, 인증서 신뢰 설정도 아닙니다. 먼저 노드에서 요구하는 값을 사용하세요. - REALITY 노드: 서버 설정에 지정된 서버 이름, 공개 키, shortId 등의 매개변수가 일치해야 합니다. 버전에 따라 항목 이름이 다를 수 있으므로 관리자가 제공한 전체 설정을 우선 가져오세요.
- 코어 지원 여부: v2rayNG는 Xray를, v2flyNG는 V2Fly를 사용합니다. 두 코어가 지원하는 보안 및 전송 옵션은 완전히 같지 않습니다. REALITY 노드는 지원하지 않는 코어에서 TLS 옵션 하나를 바꾸는 것만으로 사용할 수 없습니다.
v2rayN은 클라이언트 인터페이스이며 실제 연결 동작은 노드에서 사용하는 코어에도 영향을 받습니다. 인터페이스를 업데이트했더라도 구버전 코어가 실행 중이면 새 매개변수가 예상대로 적용되지 않을 수 있습니다. 로그에서 코어 이름과 실행 버전을 확인한 뒤 노드 요구 사항에 맞게 업데이트하세요. 지문을 바꾼 뒤 가끔 연결된다는 이유만으로 인증서 문제가 해결됐다고 판단하지 마세요.
5. allowInsecure를 장기 해결책으로 쓰면 안 되는 이유
일반 TLS에서 allowInsecure는 안전하지 않은 인증서 검증을 허용하는 설정입니다. 켜면 일반적으로 인증서 체인과 호스트 이름을 정상적으로 검증하지 않습니다. 그렇다고 연결이 암호화되지 않는다는 뜻은 아닙니다. 문제는 정상적인 검증 절차로 상대방의 신원을 확인할 수 없다는 점입니다. 따라서 연결이 된다고 해서 설정이 올바른 것은 아닙니다.
증상: 인증서 검증을 건너뛰면 연결됨
원인 및 해결: 인증서 검증과 관련된 문제일 수 있지만, 시간 오류, 이름 불일치, 체인 누락, 인증서 대체 중 무엇이 원인인지는 아직 알 수 없습니다. 검증을 다시 켜고 로그에 따라 항목별로 수정하세요. 연결됐다는 사실만으로 상대방을 신뢰할 수 있다고 판단해서는 안 됩니다.
증상: 인증서 검증을 건너뛰어도 시간 초과
원인 및 해결: 연결이 인증서 검증 단계까지 도달하지 못했거나 전송 설정 또는 접속 정책에 문제가 있을 수 있습니다. 주소, 포트, 네트워크 연결 상태, 서버 로그를 확인하고 관련 없는 옵션을 계속 추가하지 마세요.
인가된 통제 테스트 환경에서는 관리자가 원인 범위를 좁히기 위해 검증 옵션을 잠시 변경할 때도 있지만, 신뢰할 수 없는 네트워크에서 이를 일상적인 연결 방법으로 사용해서는 안 됩니다. 특히 계정 로그인, 구독 정보 가져오기, 민감한 요청을 처리할 때는 검증 가능한 연결을 먼저 확보하세요. 자체 인증서 체계를 사용하는 경우 코어에서 지원하는 신뢰 설정으로 올바르게 신뢰를 구성하고, 검증을 계속 건너뛰지는 마세요.
- 테스트 후 설정을 복구하지 못하는 일이 없도록 기존 노드 설정을 저장하거나 화면을 캡처하고, 원래 인증서 검증 옵션도 기록하세요.
- 정상적인 인증서 검증을 켠 상태에서 한 번 재현하고 전체 내부 오류 로그를 보관하세요.
- 시간 보정이나 SNI 수정처럼 근거가 있는 항목 하나만 바꾸고 다시 연결하세요.
- 문제를 해결한 뒤
allowInsecure가false인지, 또는 화면의 ‘인증서 검증 건너뛰기’가 꺼져 있는지 확인하세요.
6. 재확인 목록: 인증서 통과 후에도 접속되지 않는다면
TLS 핸드셰이크 성공은 여러 단계 중 하나일 뿐입니다. 이후 WebSocket 핸드셰이크, gRPC 서비스 일치 여부, 프록시 프로토콜 인증, 대상 도메인 확인에서도 문제가 생길 수 있습니다. 새 로그에 더 이상 x509 오류가 없고 HTTP 상태 코드 오류나 인증 실패가 나타난다면 해당 계층을 점검하세요. 이미 올바른 SNI를 계속 바꾸지 마세요.
시간을 동기화했는데도 인증서가 만료됐다고 표시되는 이유는 무엇인가요?
새 로그를 확인해 오래된 기록이 아닌지 살펴본 다음, 관리자가 현재 접속 지점에서 실제로 반환하는 인증서를 확인하도록 요청하세요. 갱신된 인증서 파일을 서버에서 다시 불러오지 않았거나 로드밸런서의 일부 접속 지점이 이전 인증서를 계속 사용하는 경우에도 오류가 발생할 수 있습니다.
휴대폰에서는 연결되는데 컴퓨터에서는 안 됩니다. SNI를 바꿔야 하나요?
먼저 두 기기의 전체 노드 설정, 사용 중인 코어와 시간을 비교한 뒤 연결된 네트워크를 확인하세요. 컴퓨터에서 보안 프로그램이 인증서를 대체하지 않았는지, 다른 접속 지점에 연결된 것은 아닌지도 살펴보세요. 기기 차이만으로 SNI 오류라고 단정할 수는 없습니다.
WebSocket에서 400 또는 404를 반환하면 TLS 문제인가요?
HTTP 응답이 왔다면 보통 HTTP 계층까지 연결된 것입니다. WebSocket Host, path, 리버스 프록시 규칙을 확인하세요. 기본 사이트의 응답을 노드가 정상 작동한 결과로 오해하지 않도록 예상한 서비스가 응답한 것인지도 확인해야 합니다.
구독을 업데이트한 뒤 방금 수정한 설정이 다시 바뀌었습니다.
구독 업데이트가 노드 항목을 덮어쓸 수 있습니다. 노드를 복사해 별도로 테스트하고 수정한 항목을 기록한 뒤 구독 제공자에게 원본 설정 수정을 요청하세요. 업데이트할 때마다 설정을 수동으로 다시 입력하는 방식에 장기간 의존하지 마세요.
문제 해결을 요청할 때 어떤 정보를 제공해야 하나요?
클라이언트와 코어 버전, 시스템 시간, 오류 발생 시각, 민감한 정보를 가린 원본 로그, TLS 또는 REALITY 사용 여부를 제공하세요. 네트워크를 바꿨을 때 결과가 달라지는지도 설명하세요. 전체 공유 링크나 구독 인증 정보를 공개하지 마세요.
최종 점검에서는 인증서 검증을 켜 둔 채 같은 노드로 연결, 대상 사이트 접속, 연결 해제 후 재연결까지 완료하세요. 오류가 사라지고 실제 요청도 정상적으로 처리되어야 이번 문제 해결이 끝난 것입니다. 기본 설정 항목은 용어 안내에서 확인할 수 있습니다. 네트워크, 프록시 연결, 코어 문제를 구분하려면 기술 참고 자료를 살펴보세요.