TUN stack이 실제로 바꾸는 것
TUN은 운영체제에 가상 터널 인터페이스를 올리고, 지정한 트래픽을 코어 안의 라우팅·프록시 파이프라인으로 보냅니다. 이때 “스택”은 그 경계에서 TCP·UDP 세션을 어떤 계층에서 흉내 내고 넘길지를 가리키는 구성에 가깝습니다. gvisor 쪽은 사용자 공간에서 네트워크 스택을 일부 재구현해 격리·이식성을 높이는 방향이고, system(표기는 클라이언트·버전마다 조금 다름)은 OS가 제공하는 경로·소켓 동작에 더 기대는 쪽으로 이해하면 디버깅 대화가 쉬워집니다.
중요한 점은 스택 이름만 바꿔도 UDP 포워딩·ICMP·일부 ioctl 동작·멀티 경로가 미묘하게 달라질 수 있다는 것입니다. 그래서 “규칙은 DIRECT인데 앱만 이상하다”거나 “HTTP는 되는데 음성·게임만 안 된다”는 증상에서 스택을 한 번 바꿔 비교하는 비용이 낮은 편입니다.
gvisor와 system, 한 줄 요약부터
대략 다음처럼 기억해 두면 선택이 빨라집니다. 다만 OS·드라이버·다른 VPN과의 경합에 따라 예외가 있으므로 “원칙 + AB 테스트”가 전제입니다.
- gvisor: 코어가 네트워크 스택을 더 많이 붙잡는 대신, 환경 간 재현성·일부 이기종 앱 조합에서 안정적일 때가 있습니다. 반대로 극단적으로 지연에 민감한 게임이나 특정 QUIC 구현이 사용자 공간 경로와 잘 안 맞으면 추가 지연·간헐 끊김으로 나타날 수 있습니다.
- system: OS 네이티브 스택에 더 의존하므로, 로컬 NIC·WFP·pf·라우팅 테이블과의 정합이 좋을 때 체감 핑·UDP 반응이 유리한 경우가 많습니다. 대신 다른 터널 프로그램·보안 제품·구형 드라이버와 충돌하면 OS 의존 버그가 표면화하기도 합니다.
호환성: 어떤 조합에서 먼저 의심하나
gvisor를 먼저 시도하기 좋은 신호
- 같은 기기에서 여러 VPN·가상 스위치·보안 에이전트가 겹쳐 있고, system에서만 간헐적으로 터널이 비거나 복귀가 이상하다.
- 특정 상용 앱이 OS 스택과 함께 쓸 때만 로컬 루프백·분할 터널 판단을 헷갈린다.
- 컨테이너·특수 리눅스 배포판 등 커널·모듈이 낯선 환경에서 TUN을 실험 중이다.
system을 먼저 시도하기 좋은 신호
- FPS·격투·리듬처럼 짧은 RTT 변동에 민감한 온라인 게임이거나, 음성 채팅에서만 패킷 드랍이 잦다. UDP·WebRTC는 Discord·UDP 글과 같이 보면 로그 읽기가 수월합니다.
- 브라우저나 메신저가 QUIC/HTTP3로만 붙는 구간이 끊기고, 동일 노드에서 TCP 위주 트래픽은 비교적 안정적이다.
- 이미 OS 방화벽·라우팅과 Clash TUN을 오래 맞춰 왔고, 다른 터널과의 충돌이 거의 없다.
참고: 키 이름은 GUI에 따라 tun.stack, stack, 고급 플래그 텍스트 등으로 다르게 보일 수 있습니다. 항상 저장한 YAML 또는 런타임 설정 덤프로 실제 값을 확인하세요.
지연·QUIC·게임에서 보이는 패턴
QUIC은 UDP 위에서 동작하며, 일부 클라이언트는 실패 시 TCP로 잘 떨어지지만 앱마다 정책이 다릅니다. 스택을 바꿨을 때 “웹만 가끔 새로고침하면 된다”에서 “스트리밍 버퍼만 길어진다”로 바뀌는 경우, 실제로는 UDP 경로·MTU·분할 라우팅이 함께 바뀐 결과일 수 있습니다.
게임 측면에서는 평균 핑보다 지터(왕복 시간의 들쭉날쭉함)가 체감에 더 큰 경우가 많습니다. gvisor 경로가 앱별로 지터를 줄이기도·늘리기도 하므로, 동일 서버·동일 노드로 20~30분 이상 플레이 AB 테스트를 권장합니다. 짧은 샘플은 Wi-Fi 혼잡만으로도 결론이 뒤집힙니다.
의사결정 순서 (실무용)
- TUN이 실제로 해당 앱 트래픽을 잡는지(시스템 프록시만 켠 것은 아닌지) 확인한다. 필요하면 TUN 가이드의 범위 설정을 다시 본다.
- 충돌 가능한 다른 VPN·가상 어댑터를 끄고, system으로 짧게 재현 테스트를 한다.
- 게임·QUIC 이슈가 남으면 gvisor로 바꿔 같은 시나리오를 반복한다.
- 둘 다 비슷하면 스택은 중립으로 두고, 다음 절의 DNS·규칙·환경 변수로 넘어간다.
스택을 고른 뒤: DNS, 규칙, 환경 변수
스택을 바꿔도 증상이 그대로면, 원인은 종종 코어 밖에 있습니다. 우선순위를 정해 두면 시간 낭비가 줄어듭니다.
DNS: FakeIP·DoH·폴백 조합이 앱별로 다른 해석을 만들면 “패킷은 TUN을 타는데 목적지 선택이 매번 갈린다”는 형태로 나타납니다. 전체 그림은 Meta 코어 DNS 유출 방지 가이드로 잡고, 문제 앱의 도메인만 좁혀 nameserver-policy나 GUI의 DNS 프로필을 정리합니다.
규칙: PROCESS-NAME·DOMAIN-SUFFIX·GEOIP의 순서가 바뀌면 동일 스택에서도 결과가 달라집니다. 음성·게임은 UDP 행이 로그에 찍히는지 먼저 확인합니다.
환경 변수: 일부 GUI는 코어 실행 전 HTTPS_PROXY 등을 주입합니다. TUN과 이중으로 걸리면 앱이 예상과 다른 경로를 탑니다. 변경 후에는 코어 완전 재시작으로 환경이 반영됐는지 확인하세요.
프로필에 넣을 때 보는 자리 (개념 예시)
실제 키 이름은 버전과 프리셋에 따라 다릅니다. 아래는 “어디를 보러 가야 하는지”를 위한 개념 스케치이며 그대로 복붙하면 안 될 수 있습니다.
# Conceptual — align keys with your client / core version
tun:
enable: true
stack: system # or gvisor — verify against your YAML dump
# other tun fields (mtu, strict-route, etc.) affect path too한 페이지 점검표
- TUN 인터페이스가 OS에 올라와 있고, 문제 앱이 그 인터페이스 아래로 들어오는지.
- system ↔ gvisor 단일 변수만 바꾼 AB 테스트 로그를 남겼는지.
- 동일 증상에서 DNS·FakeIP·스니퍼·규칙 순서를 한 축씩 고정했는지.
- 다른 VPN·필터 드라이버·사내 보안 에이전트가 동시에 붙어 있지 않은지.
- 노드 자체의 UDP 제한·지역 라우팅은 스택과 무관하게 배제했는지.
주의: 네트워크 정책·서비스 약관을 준수하고, 허용된 환경에서만 노드·프록시를 사용하세요. 본문은 기술적 트러블슈팅을 위한 일반 설명입니다.
오픈소스와 설치 경로
Mihomo·GUI 포크의 변경 이력·이슈는 GitHub에서 확인할 수 있지만, 설치 패키지를 받는 주된 경로는 공식 Clash 다운로드 페이지를 권장합니다. 소스는 신뢰 확인용, 일상 설치는 사이트 안내로 통일하면 혼선이 줄어듭니다. 설정 전체 구조는 문서 허브 목차와 맞춰 두면 스택 변경 후에도 추적이 쉽습니다.
정리
Clash Meta·Mihomo의 TUN에서 gvisor와 system은 “같은 토글”처럼 보여도 호환성과 UDP·QUIC·게임 체감에 다른 트레이드오프를 줍니다. 먼저 한쪽을 고정해 재현률을 본 뒤, 남는 문제는 DNS·규칙·실행 환경 변수로 넘어가면 탐색 공간이 줄어듭니다. 스택만 바꾸며 노드를 몇 dozen 번 갈아 끼우는 것보다, 로그 한 줄이 어떤 스택·어떤 규칙을 탔는지를 남기는 편이 훨씬 값이 큽니다.
장기 운영 측면에서 규칙·로그·프로필을 한 화면에서 다루기 쉬운 Clash 계열은, 이런 “한 변수씩” 실험을 반복하기에도 유리합니다.