1. TLS handshake timeout이 의미하는 것
HTTPS·TLS를 쓰는 연결은 대략 TCP 연결 → TLS 핸드셰이크(암호 스위트·인증서·SNI 교환) 순으로 진행됩니다. 클라이언트나 중간 프록시 로그에 TLS handshake timeout, i/o timeout, context deadline exceeded처럼 핸드셰이크 단계에서 시간이 초과했다는 문구가 붙으면, “앱이 아직 HTTP 요청 본문을 보내기도 전에 막혔다”는 뜻에 가깝습니다. 따라서 브라우저가 보여 주는 일반적인 “사이트에 연결할 수 없음”보다 한 단계 앞, 암호화 터널을 여는 구간에서 병목이 있다는 신호로 읽는 것이 좋습니다.
다만 이 문자열 하나만으로는 원격 서버가 느린 것인지, 중간 프록시(노드)가 응답을 못 받는 것인지, SNI·인증서 검증에서 막힌 것인지, 로컬에서 잘못된 IP로 붙으려다 망한 것인지 구분되지 않습니다. 그래서 실무에서는 로그에 찍힌 프록시 그룹·선택된 노드 이름, 목적지 IP·포트·호스트, 필요하면 스니퍼가 복원한 도메인을 먼저 적어 두고, 아래 순서로 층을 하나씩 지워 나가는 편이 가장 덜 헛돕니다. TUN으로 전체가 끊기는 패턴은 TUN·라우팅 점검 글과 겹치므로, 이 글은 전형적인 TLS 오류 문자열과 노드·SNI·규칙에 초점을 맞춥니다.
2. 로그에서 노드·목적지·SNI 읽기
대부분의 Clash 계열 클라이언트는 연결마다 어떤 규칙에 매칭됐는지, 어느 프록시 그룹의 어느 노드로 나갔는지를 로그나 디버그 패널에 남깁니다. 문제가 난 시각에 가장 가까운 줄부터 거꾸로 올라가며 다음을 확인하세요. 첫째, 해당 연결이 DIRECT인지 REJECT인지, 아니면 구독에 묶인 특정 노드인지. 둘째, 목적지가 198.18.x.x 같은 fake-ip 대역인지, 실제 공인 IP인지. 셋째, TLS 관련 줄에 서버 이름(SNI)이 따로 찍히는지, 스니퍼가 개입했다는 설명이 있는지.
같은 사이트라도 리다이렉트 때문에 여러 호스트명이 순서대로 등장할 수 있으므로, 브라우저 개발자 도구의 네트워크 탭에서 실패한 요청의 호스트와 로그의 SNI를 나란히 놓고 비교하면 빨리 맞춰집니다. 여기까지가 “무엇이 실패했는지”를 고정하는 단계이고, 아직 노드를 갈아엎을 단계는 아닙니다. 로그에 RULE 태그나 정책 이름이 보이면 다음 절의 규칙 점검으로 이어지기 쉽습니다.
3. 노드 품질과 지연: 먼저 배제할 층
핸드셰이크 타임아웃의 상당수는 솔직히 노드 지연·포화·일시 차단에서 옵니다. 같은 사이트를 다른 노드나 다른 프록시 그룹으로만 바꿨을 때 즉시 살아난다면, 규칙보다 먼저 출구 품질을 의심하는 편이 맞습니다. 구독에 url-test·fallback 그룹이 있다면 지연·패킷 손실 지표가 튀는지 보고, 수동으로라도 지역이 다른 에지를 골라 A/B 테스트해 보세요.
반대로 모든 노드에서 같은 호스트만 타임아웃이고 다른 사이트는 정상이라면, 노드 전체가 동시에 죽었을 가능성은 낮습니다. 이 경우에는 차단 정책(SNI 기반 필터), 목적지 측 장애, 혹은 잘못된 DNS 해석으로 엉뚱한 IP의 443에 붙는 경우를 의심해야 합니다. 즉 “노드 테스트”는 필수지만, 그 결과를 도메인 단위로 해석해야 헛발질이 줄어듭니다.
빠른 체크리스트
- 동일 URL·다른 노드: 한두 대만 바꿔도 재현되는가.
- 동일 노드·다른 URL: 같은 출구에서 다른 HTTPS 사이트는 열리는가.
- 시간대: 특정 시간대에만 터지면 대역폭·QoS 가능성.
4. SNI·인증서·중간 장비
TLS 1.3 환경에서도 클라이언트 헬로에는 서버 이름 표시(SNI)가 실려 가는 경우가 많고, 일부 회선·상용 필터·보안 장비는 SNI 문자열을 보고 연결을 늦추거나 끊습니다. 로그에 목적지 IP는 맞는데 핸드셰이크만 영원히 돌거나, 특정 국가의 노드에서만 같은 증상이 반복되면 경로 상 SNI 검열을 염두에 두는 것이 좋습니다. 이때는 다른 프로토콜(예: QUIC이 꺼진 상태의 순수 TCP 443)로만 비교해 보거나, 클라이언트가 제공하는 현실적인 우회 전송 방식이 있다면 그 경로로만 A/B하는 식으로 범위를 좁힙니다.
또 한 축은 인증서 이름 불일치입니다. 중간 프록시가 잘못된 인증서를 끼워 넣거나, 기업 루트 인증서를 신뢰하지 않는 앱이면 핸드셰이크 직전에 끊길 수 있습니다. 브라우저는 자세한 경고를 주지만, 일부 네이티브 앱은 timeout 한 줄로만 보여 주기도 합니다. 시스템 시계가 크게 틀어져 있으면 인증서 유효 기간 검증에서도 비슷한 증상이 나므로, 휴대폰이나 PC의 자동 시각 동기화도 함께 확인하세요.
5. 스니퍼·fake-ip와 규칙 매칭
스니퍼는 암호화된 연결에서도 규칙 엔진이 도메인을 알 수 있게 TLS Client Hello의 SNI 등을 읽어 옵니다. 범위를 넓게 켜 두면 특정 앱·게임·금융 사이트에서 핸드셰이크가 비정상적으로 길어지거나 끊기는 현상과 겹칠 수 있습니다. 점검은 단순합니다. 스니퍼를 잠시 끄거나 허용 프로토콜·포트만 좁힌 뒤 같은 URL을 다시 열어 봅니다. 증상이 사라지면 노드보다 스니퍼 정책을 먼저 다듬는 편이 낫습니다.
fake-ip와 스니퍼가 같이 켜진 템플릿은 흔합니다. 일부 호스트는 가짜 IP를 받은 뒤에도 앱 내부에서 다시 해석하거나 SNI를 엄격히 맞추기 때문에, 겉으로는 TLS 타임아웃만 보일 수 있습니다. 이런 층을 분리하려면 fake-ip·DNS·스니퍼 점검 글의 순서(fake-ip-filter, DNS 업스트림, 스니퍼 범위)를 함께 참고하는 것이 좋습니다. 한 번에 여러 스위치를 바꾸지 말고, 로그에 적어 둔 한 연결만 놓고 변수를 하나씩 제거하세요.
규칙이 의도와 다를 때
로그에 찍힌 RULE가 생각과 다르면, 트래픽이 DIRECT로 새어 나가 차단된 출구를 타거나, 반대로 REJECT 계열에 걸려 조용히 끊길 수도 있습니다. PROCESS·DOMAIN-SUFFIX·GEOSITE 등 규칙 우선순위를 위에서부터 다시 읽고, 문제 호스트가 어느 줄에서 매칭되는지 확인하세요. 스니퍼가 복원한 이름과 실제 브라우저가 여는 호스트가 다르면, 규칙은 “맞는 것처럼” 보이는데 출구만 어긋나는 패턴도 생깁니다.
| 로그·증상 단서 | 우선 의심 층 |
|---|---|
| 노드만 바꾸면 즉시 해결 | 해당 에지 지연·차단·포화 |
| 스니퍼 끄면 완화 | 스니퍼 범위·override·특정 앱 호환 |
| 목적지가 fake-ip 대역 | fake-ip-filter·DNS 해석 경로(관련 글) |
| RULE가 DIRECT인데만 실패 | 로컬 DNS·ISP 차단·본문 앱의 프록시 무시 |
6. 로컬 DNS와 해석 경로
Clash 밖에서 시스템이나 브라우저가 먼저 다른 DNS를 쓰고 있으면, 앱은 “정상 IP”로 보이는 목적지에 연결했는데 중간에서 Clash가 다시 가로채면서 서로 다른 해석 결과가 섞일 수 있습니다. WSL·Docker·가상머신을 같이 쓰는 환경은 특히 그렇습니다. WSL2와 DNS를 다룬 글처럼, 질의가 실제로 어디로 나가는지를 먼저 고정하는 습관이 있으면 TLS 타임아웃도 빨리 줄어듭니다.
Clash 내부 DNS를 쓰는 경우에는 nameserver·fallback·nameserver-policy가 과하게 공격적이면 잘못된 대륙의 IP를 받아 와 핸드셰이크만 길게 타는 것처럼 보이기도 합니다. DoH 호스트가 막힌 Wi-Fi에서는 UDP DNS로만 잠시 바꿔 보는 등, 업스트림 가용성을 먼저 확인한 뒤 fake-ip 여부를 논의하세요.
정리하면, TLS handshake timeout은 “암호화 전 단계”의 병목 신호이지만 원인은 노드 한 줄에만 있지 않습니다. 로그로 출구와 SNI를 고정하고, 노드 A/B로 출구 품질을 배제한 다음, 스니퍼·fake-ip·규칙·로컬 DNS 순으로 좁히면 같은 증상이라도 수리 위치가 분명해집니다.
7. 요약과 다음 단계
이 글의 순서는 로그에서 연결 한 줄을 고정하고 → 노드 품질을 빠르게 배제한 뒤 → SNI·인증서·중간 장비를 짚고 → 스니퍼와 규칙 매칭을 맞추고 → 마지막에 로컬·클라이언트 내부 DNS를 보는 흐름입니다. TUN으로 전역이 끊기거나 방화벽이 가로채는 경우는 별도의 체크리스트가 필요하므로, 앞서 인용한 TUN 글과 병행하는 것을 권합니다.
반복되는 도메인마다 “노드 문제였는지, SNI였는지, fake-ip였는지”를 짧게 메모해 두면 다음에 구독이 바뀌어도 같은 검색을 다시 하지 않아도 됩니다. 클라이언트 설치와 기본 경로는 문서 허브에서 정리되어 있으니, 먼저 안정적인 빌드를 받은 뒤 이 순서로 로그를 읽으면 됩니다.
다른 범용 프록시 도구에 비해 Clash 계열은 규칙·DNS·모드 조합을 로그와 함께 다루기 좋은 편이라, 타임아웃 한 줄도 “어디까지 왔다가 멈췄는지”를 추적하기에 적합합니다.