Clash프로토콜 및 커널 참고서

01 · DECISION MODEL

먼저 프로토콜 선택 프레임워크 세우기

프로토콜 이름은 속도 순위가 아닙니다

Clash Plus, Clash Verge Rev, FlClash 등의 클라이언트에서 노드 옆에 표시되는 SS, VMess, Trojan, VLESS, Hysteria2, TUIC은 우선 클라이언트와 서버가 데이터를 주고받을 때 사용하는 프로토콜 구조를 뜻합니다. 속도순으로 바로 나열할 수 있는 제품 목록이 아닙니다. 실제 연결 성능은 서버 처리 능력, 경로 왕복 시간, 패킷 손실률, 혼잡도, 전송 계층, 암호화 구현, 클라이언트 커널과 기기 성능의 영향을 함께 받습니다. 같은 프로토콜이라도 경로와 서버 부하에 따라 두 노드의 성능은 크게 달라질 수 있으며, 반대로 안정적인 네트워크에서는 서로 다른 프로토콜도 비슷한 웹 로딩 경험을 제공할 수 있습니다.

따라서 프로토콜 선택은 먼저 호환 가능 여부를 확인하고, 현재 네트워크에 적합한지 판단한 뒤, 마지막으로 속도를 비교해야 합니다. 호환성에는 클라이언트 커널의 프로토콜 지원 여부, 구독 변환 과정에서 필요한 필드가 보존되는지, 전송 계층 조합이 구현되어 있는지, 기기 운영체제가 UDP 또는 QUIC 세션을 정상적으로 수립할 수 있는지가 포함됩니다. 가져오는 과정에서 핵심 필드가 이미 사라졌다면 이후 속도 측정은 의미가 없습니다. 일반 사용자는 서비스 제공자가 검증한 완전한 설정을 우선 사용하는 편이 안정적입니다. 한 프로토콜의 이름만 바꾼다고 다른 프로토콜로 변환되는 것은 아닙니다.

영향 요인을 네 가지 계층으로 나누기

첫 번째 계층은 기본 네트워크입니다. 고정 회선은 지연과 패킷 손실이 비교적 안정적이어서 TCP 기반 방식이 매끄럽게 작동하기 쉽습니다. 모바일 데이터, 공용 Wi-Fi, 통신사 간 경로에서는 순간적인 패킷 손실과 네트워크 전환이 발생할 수 있습니다. 이때 UDP 기반이며 혼잡 제어 기능을 갖춘 Hysteria2나 TUIC이 더 잘 대응할 수 있지만, 네트워크가 안정적인 UDP 전송을 허용해야 합니다. 두 번째 계층은 서버와 경로입니다. 같은 프로토콜이라도 서버 CPU 포화, 출구 혼잡, 우회 라우팅이 발생하면 클라이언트에서 파라미터를 바꿔도 병목은 사라지지 않습니다.

세 번째 계층은 프로토콜과 전송 방식의 조합입니다. VMess와 VLESS는 TCP, WebSocket, gRPC 등을 함께 사용할 수 있으며, VLESS는 TLS, REALITY 같은 보안 계층과도 자주 조합됩니다. SS는 간결한 암호화 프록시 구조에 가깝고, Trojan은 TLS 의미 체계에 의존합니다. Hysteria2와 TUIC은 QUIC 또는 UDP 전송 방식에 기반합니다. 네 번째 계층은 클라이언트 구현입니다. mihomo는 최신 프로토콜과 규칙 기능을 더 폭넓게 지원하지만, 초기 원본 Clash의 설정 기능은 제한적입니다. 선택할 때는 이 네 계층을 함께 살펴보고 네트워크·경로·커널 문제를 모두 프로토콜 이름 탓으로 돌리지 않아야 합니다.

테스트할 때 기록할 항목

클라이언트의 지연 시간 테스트는 일반적으로 한 번의 탐색 요청만 반영하므로 장시간 연결의 처리량과 안정성을 완전히 보여 주지 못합니다. 실용적인 테스트에는 네 가지 항목이 포함되어야 합니다. 여러 사이트의 첫 로딩 응답 속도, 일정 시간 다운로드한 뒤의 처리량 변동, 영상이나 회의 중 끊김 여부, 기기 잠금 후 다시 깨웠을 때의 복구 속도입니다. 매번 같은 네트워크와 서버에서 프로토콜만 바꾸거나, 같은 프로토콜로 Wi-Fi와 모바일 데이터를 비교하는 등 한 번에 하나의 변수만 바꾸세요. 노드·네트워크·클라이언트·프로토콜을 동시에 바꾸면 개선이 어느 계층에서 발생했는지 알 수 없습니다.

로그에서 실패 지점도 확인해야 합니다. 도메인 해석 오류, 연결 시간 초과, 인증 실패, TLS 핸드셰이크 오류, UDP 연결 불가 현상은 각각 다른 문제를 가리킵니다. 로그에 인증 실패가 표시된다면 전역 모드를 반복해서 바꿔도 해결되지 않습니다. DNS 해석 이상이라면 프로토콜을 바꿔도 효과가 없을 수 있습니다. 로그 페이지와 프록시·설정 페이지의 관계는 Clash Verge 인터페이스 기능 한눈에 보기에서 확인할 수 있습니다. 이런 계층별 점검 방식을 익히면 프로토콜 선택은 ‘어떤 이름을 시도할까’가 아니라 반복 가능하고 검증 가능한 기술적 판단이 됩니다.

03 · CURRENT OPTIONS

VLESS·Hysteria2·TUIC의 사용 범위

VLESS: 인증 계층과 암호화 계층을 나누어 이해하기

VLESS는 UUID 등의 정보로 클라이언트 신원을 표현하지만, 프로토콜 자체가 VMess와 같은 내장 암호화 방식을 제공하지는 않습니다. 실제 연결 보안은 일반적으로 TLS, REALITY 또는 다른 외부 계층이 담당합니다. VLESS를 이해할 때는 프로토콜, 전송 계층, 보안 계층을 분리해서 봐야 합니다. VLESS는 인증과 전달 구조의 일부를 결정하고, TCP·WebSocket·gRPC 등은 전송 방식을, TLS 또는 REALITY는 보안 핸드셰이크를 결정합니다. 클라이언트 목록에 VLESS만 표시되더라도 설정을 펼쳐 network, tls, servername, reality-opts, flow 필드를 확인해야 합니다.

VLESS 설정의 flow는 임의로 입력하는 성능 스위치가 아닙니다. 일부 조합은 특정 흐름 제어 값을 사용하며 클라이언트, 서버, 하위 구현이 모두 일치해야 합니다. 잘못된 값은 대개 핸드셰이크나 데이터 전송 실패로 이어집니다. REALITY 설정에는 public-key, short-id, servername이 포함될 수 있으며 이 필드들은 서로 연관되어 있습니다. 구독 변환 과정에서 필드명이 바뀌거나 빈 값을 삭제하면서 필요한 파라미터까지 사라지거나, 오래된 클라이언트가 해당 구조를 인식하지 못하면 노드는 존재하지만 연결되지 않을 수 있습니다. 따라서 VLESS는 mihomo를 지원하는 최신 클라이언트로 완전하게 가져오는 편이 좋습니다.

Hysteria2: 패킷 손실이 많은 경로를 위한 QUIC 방식

Hysteria2는 UDP 기반 QUIC 전송 위에서 동작하며, 최신 혼잡 제어와 다중화를 활용해 지연·지터·패킷 손실이 큰 경로에 대응하는 데 초점을 둡니다. 그렇다고 모든 네트워크에서 더 빠른 것은 아닙니다. 로컬 UDP 경로가 안정적이고 서버 대역폭이 충분하며 파라미터가 적절하면 지속 전송에서 좋은 처리량을 유지할 수 있습니다. 반대로 로컬 네트워크가 UDP를 제한하거나 경로 품질이 낮거나 중간 장비가 UDP 세션을 자주 회수하면 연결 시간 초과, 속도 변동, 대기 후 복구 지연이 발생할 수 있습니다.

일반적인 설정 필드에는 서버 주소, 포트, 인증 정보, TLS server name, 인증서 검증, 대역폭 관련 파라미터가 포함됩니다. 대역폭 값은 혼잡 제어가 전송 속도를 판단하도록 돕는 값이지, 숫자를 크게 입력한다고 속도가 높아지는 것은 아닙니다. 실제 회선보다 훨씬 높게 설정하면 대기열과 패킷 손실이 발생할 수 있고, 너무 낮으면 처리량이 제한됩니다. 최신 구현은 모드에 따라 자동 조정할 수도 있으므로 구독에서 내려온 값을 사용하는 편이 안전합니다. 로그에 UDP timeout이 표시되면 대역폭 값만 계속 높이지 말고 먼저 다른 네트워크에서 테스트한 뒤 방화벽, 라우터, 서버 포트를 확인하세요.

TUIC: 낮은 지연 시간의 세션과 UDP 전송

TUIC도 QUIC와 UDP를 기반으로 하며 빠른 연결 수립, 다중화, 헤드 오브 라인 블로킹 영향 감소에 초점을 둡니다. 설정에는 보통 UUID, 비밀번호, 서버 이름, 혼잡 제어 옵션, UDP 릴레이 모드가 포함됩니다. 구현이나 설정 세대에 따라 필드가 다를 수 있으므로 구독의 프로토콜 식별자, 버전 의미, 인증 구조가 서버와 일치해야 합니다. mihomo는 일반적인 TUIC 설정을 인식할 수 있지만, 오래된 커널이나 클라이언트는 해석하지 못할 수 있습니다. 가져온 뒤 무시되었다고 구독이 비어 있는 것은 아니며, 커널이 해당 노드 유형을 지원하지 않는 것일 수 있습니다.

TUIC은 세션을 자주 만들고 네트워크 품질이 변동하며 UDP를 사용할 수 있는 환경에 적합하지만 TCP의 완전한 대체재는 아닙니다. 기업 Wi-Fi, 게스트 네트워크, 일부 이동통신망, 엄격하게 설정된 라우터는 UDP를 제한할 수 있으며 이 경우 TUIC과 Hysteria2가 함께 작동하지 않을 수 있습니다. 실제 설정에는 SS, Trojan 또는 다른 TCP 전송 노드를 대체 경로로 남겨 두세요. 음성, 게임, 실시간 통신에서는 클라이언트와 서버 사이가 UDP인지와 대상 애플리케이션이 UDP 전달을 거치는지를 구분해야 합니다. 전자가 가능하다고 후자의 규칙과 정책까지 올바르다는 뜻은 아닙니다.

proxies:
  - name: "VLESS-Reference"
    type: vless
    server: node.example.invalid
    port: 443
    uuid: 00000000-0000-4000-8000-000000000000
    network: tcp
    tls: true
    servername: node.example.invalid

  - name: "Hysteria2-Reference"
    type: hysteria2
    server: node.example.invalid
    port: 443
    password: "your-password"
    sni: node.example.invalid

위 예시는 mihomo YAML에서 필드 계층을 설명하기 위한 것으로, 주소·신원·비밀번호는 명확한 예시 값이며 그대로 연결에 사용할 수 없습니다. 실제 구독은 VLESS에 REALITY 파라미터를 추가하거나 Hysteria2에 포트 범위와 대역폭 설정을 추가하는 등 다른 필드 조합을 사용할 수 있습니다. 설정을 편집한 뒤에는 먼저 클라이언트의 설정 검사 기능을 실행하고, 로그에 unsupported, missing field, authentication, handshake 등이 표시되는지 확인하세요. 구독에서 가져온 설정이라면 구독 원본에서 수정하거나 대상 형식을 명확히 지원하는 변환 방식을 사용해 업데이트 때마다 로컬 수정 사항이 덮어쓰이지 않도록 하세요.

05 · MOBILE AND PLATFORM

모바일 배터리·네트워크 전환·플랫폼 차이

배터리 소모는 지속적인 동작 방식에서 발생합니다

모바일 배터리 성능을 프로토콜의 암호화 강도와 단순히 연결해서는 안 됩니다. 주요 영향 요인은 무선 모듈이 활성 상태로 유지되는 시간, 연결 재수립 빈도, 백그라운드 연결 유지 방식, 전체 데이터 전송량, DNS 요청 수, 규칙 매칭 부담, CPU 처리 시간입니다. 어떤 프로토콜이 작업을 빠르게 끝내 무선 모듈을 저전력 상태로 되돌린다면 순간 CPU 사용량이 조금 높아도 총 에너지 소비는 낮을 수 있습니다. 반대로 불안정한 네트워크에서 계속 재전송하거나 자주 재연결하면 한 번의 처리가 가벼워도 배터리를 더 많이 소모할 수 있습니다.

SS는 설정이 간단하고 경로가 안정적일 때 처리 부담이 낮은 편입니다. Trojan, VMess, VLESS에 TLS를 조합하면 핸드셰이크와 암호화 비용이 발생하지만 장시간 연결 재사용이 정상이라면 지속 사용에서 차이가 크지 않을 수 있습니다. Hysteria2와 TUIC은 UDP 또는 QUIC 세션을 유지하므로 네트워크가 안정적일 때 일부 대기 시간을 줄일 수 있습니다. 반면 기기가 기지국을 자주 전환하거나 라우터가 UDP 매핑을 회수하거나 백그라운드 정책이 활동을 제한하면 세션 재수립으로 깨우기 횟수가 늘어날 수 있습니다. 실제 배터리 결과는 Android 제조사의 백그라운드 제한, iOS 네트워크 확장 방식, 클라이언트 구현에도 좌우되므로 프로토콜 이름만으로 예측할 수 없습니다.

Android: 백그라운드 정책과 VPN 서비스

Android 클라이언트는 일반적으로 시스템 VPN 서비스를 통해 트래픽을 처리합니다. Clash Plus, Clash Meta for Android, FlClash, Surfboard는 인터페이스와 기능 범위가 서로 다르지만 시스템 절전 정책, 백그라운드 활동 권한, 제조사 프로세스 관리의 영향을 모두 받습니다. 화면을 잠근 뒤 연결이 끊기면 먼저 클라이언트가 계속 실행 중인지, VPN 표시가 유지되는지, 시스템이 백그라운드 배터리 사용을 제한하는지 확인한 다음 프로토콜을 점검하세요. 앱 프로세스가 시스템에 의해 종료된 경우 다른 프로토콜로 바꿔도 근본 원인은 해결되지 않습니다.

Android에서는 IPv6, 비공개 DNS, 앱별 프록시, 핫스팟 공유도 확인해야 합니다. 일부 앱이 IPv6을 직접 사용하는데 설정이 IPv4만 처리하면 특정 앱만 연결되지 않을 수 있습니다. 비공개 DNS와 클라이언트의 DNS 가로채기 정책이 함께 적용되면 예상과 다른 해석 경로가 사용될 수 있습니다. 앱별 프록시는 커널로 들어가는 트래픽 범위를 바꾸므로 프로토콜을 테스트할 때 대상 앱이 실제로 포함되었는지 확인하세요. 모바일 데이터에서 Hysteria2나 TUIC에 문제가 생기면 Wi-Fi로 다시 테스트하세요. Wi-Fi는 정상인데 이동통신망에서 계속 시간 초과가 발생한다면 UDP 경로와 네트워크 정책을 우선 판단해야 합니다.

iOS: 시스템 네트워크 확장과 포그라운드·백그라운드 전환

iOS 클라이언트는 시스템이 제공하는 네트워크 확장 기능에 의존하며 연결 상태, 메모리 예산, 백그라운드 동작은 시스템이 통합 관리합니다. 이 사이트의 다운로드 목록에서 iOS 추천 클라이언트는 Clash Plus이며, iOS 다운로드 섹션에서 App Store로 이동할 수 있습니다. 사용할 때는 시스템 설정의 VPN 상태, 클라이언트 설정 활성화 여부, Wi-Fi와 이동통신망 전환 후 자동 복구 여부를 확인하세요. iOS는 일반 사용자에게 데스크톱과 같은 프로세스 제어 정보를 제공하지 않으므로 시스템 VPN 상태, 설정 로그, 네트워크 전환 결과를 중심으로 문제를 해결해야 합니다.

모바일 기기에서 UDP 기반 프로토콜을 사용할 때 네트워크를 전환하면 로컬 주소와 NAT 매핑이 바뀝니다. QUIC에는 연결 변경을 처리하는 관련 메커니즘이 있지만 실제로 원활하게 복구되는지는 클라이언트, 서버, 네트워크 경로에 달려 있습니다. 네트워크 전환 후 오랫동안 복구되지 않으면 클라이언트에서 연결을 끊었다가 다시 연결하고, 로그에 timeout이 반복되는지 확인하세요. TCP 노드는 즉시 복구되는데 UDP 노드만 계속 실패한다면 현재 네트워크가 UDP 세션에 적합하지 않은 것이므로 일시적으로 TCP 대체 노드를 사용하세요.

데스크톱 플랫폼에서 중점적으로 볼 차이

Windows, macOS, Linux는 일반적으로 스마트폰의 배터리와 백그라운드 동결 문제는 적지만 시스템 프록시, TUN 권한, 방화벽, 절전 후 복구가 더 중요합니다. Windows의 일부 앱은 시스템 프록시를 완전히 따르지 않으므로 TUN 모드나 앱 자체 설정이 필요할 수 있습니다. 스토어 앱은 루프백 제한의 영향을 받을 수 있으므로 Windows UWP 앱 루프백 제한 문제 해결을 참고하세요. macOS에서는 시스템 프록시와 가상 네트워크 인터페이스를 구분해야 하며 절전 후 연결에 문제가 생기면 시스템 프록시나 TUN을 먼저 재시작하세요. Linux에서는 데스크톱 프록시 설정, 라우팅 권한, systemd 서비스 상태, DNS 관리 구성 요소를 중점적으로 확인해야 합니다.

모바일 배터리를 평가할 때는 몇 분간의 순간 배터리 비율보다 시스템 배터리 통계로 전체 사용 주기를 관찰하는 것이 좋습니다. 비슷한 화면 사용 시간, 데이터량, 앱 작업을 유지하면서 후보 프로토콜을 각각 테스트하세요. 특정 프로토콜이 신호가 약할 때 기기를 계속 발열시키거나 백그라운드 활동 시간이 크게 늘거나, 깨운 뒤 반복적으로 재연결한다면 안정적인 노드나 대체 프로토콜로 바꾸는 것이 우선입니다. 배터리 성능은 프로토콜·네트워크·클라이언트·시스템 스케줄링이 함께 만든 결과이므로 목표는 추상적인 최소 오버헤드가 아니라 불필요한 작업을 줄이는 것입니다.

07 · SUBSCRIPTION

구독 형식과 설정 호환성 점검

구독 주소가 곧 고정 형식은 아닙니다

‘구독 링크’는 설정을 가져오는 방법을 뜻할 뿐, 반환 내용이 항상 같은 형식이라는 의미는 아닙니다. 서버는 완전한 Clash YAML, 노드만 포함한 YAML, 인코딩된 URI 목록, 특정 클라이언트용 설정을 반환할 수 있습니다. 클라이언트로 가져올 때는 먼저 내용을 받은 뒤 응답 형식에 맞춰 해석해야 합니다. 링크가 브라우저에서 열린다는 것은 서버가 데이터를 반환했다는 뜻일 뿐, 현재 클라이언트와 커널에 맞는 형식이라는 증거는 아닙니다.

완전한 Clash 또는 mihomo 설정에는 보통 프록시 노드, 정책 그룹, 규칙, DNS, 포트 설정이 포함됩니다. 노드 구독에는 proxies 데이터만 있을 수 있으며 정책 그룹과 규칙은 클라이언트 템플릿이 보완합니다. URI 목록은 ss://, vmess://, trojan://, vless://, hysteria2://, tuic:// 같은 형식으로 노드를 표현합니다. 복잡한 전송 파라미터를 URI로 표현하는 능력과 구현 일관성은 형식마다 다르므로 변환 과정에서 path, SNI, ALPN, 지문, REALITY, 혼잡 제어 필드가 가장 쉽게 누락됩니다.

가져오기 전후 네 가지 확인

첫 번째는 응답 상태입니다. 가져오기에 실패하면 구독 주소에 불필요한 공백이 없는지, 로그인 페이지·오류 페이지·빈 내용이 반환되지 않았는지 확인하세요. 두 번째는 노드 수와 프로토콜 유형입니다. 예상한 Hysteria2, TUIC, VLESS 노드가 해석 단계에서 사라지지 않았는지 확인합니다. 세 번째는 핵심 필드입니다. 노드 하나를 펼쳐 서버, 포트, 인증, TLS, 전송 설정을 확인하세요. 네 번째는 정책 그룹입니다. 노드가 정상적으로 해석되어도 현재 정책 그룹에 추가되지 않으면 프록시 화면에는 이전 노드만 표시될 수 있습니다.

구독 업데이트는 내용을 다시 가져와 병합하는 과정입니다. 업데이트 후 로컬 수정이 사라진다면 해당 수정이 구독 관리 범위에 있었던 것입니다. 파일을 직접 편집할 것이 아니라 클라이언트의 오버라이드나 설정 병합 기능을 사용해야 합니다. 업데이트 후 노드가 중복되면 내용이 같은 구독을 여러 개 활성화했거나 기존 설정이 교체되지 않았을 수 있습니다. 업데이트 시간은 정상인데 노드 내용이 바뀌지 않는다면 로그와 응답 캐시를 확인하고 구독 서비스가 실제로 새 내용을 반환하는지 점검하세요. 전체 진입 절차와 오류 분류는 Clash 구독 링크 가져오기 방법을 참고하세요.

필드가 누락되었을 때 위치 찾기

먼저 구독 원본과 클라이언트로 가져온 뒤의 노드 상세 정보를 비교하세요. 원본부터 필드가 빠져 있다면 구독 생성 단계의 문제입니다. 원본은 완전한데 클라이언트에서 사라졌다면 클라이언트 파서, 구독 변환, 커널 지원 문제일 수 있습니다. VMess와 VLESS는 network, servername, ws-opts, grpc-opts, reality-opts, flow를 중점적으로 확인하세요. Trojan은 password, sni, TLS를, SS는 cipher, password, plugin을, Hysteria2와 TUIC은 인증, SNI, 혼잡 제어, UDP 관련 옵션을 확인해야 합니다.

다음으로 설정 검사 오류를 확인하세요. YAML은 들여쓰기에 민감하므로 목록 항목, 매핑, 문자열 계층이 잘못되면 전체 설정을 읽지 못할 수 있습니다. 노드 이름에 콜론, 샵, 특수 문자가 포함되면 따옴표를 사용하는 편이 모호함을 줄입니다. 포트는 숫자 의미를 유지해야 하며 UUID, 비밀번호, 경로는 일반적으로 문자열로 처리하는 등 불리언·숫자·문자를 혼용해서는 안 됩니다. 수동 편집 후에는 먼저 커널의 문법 검사를 통과시킨 다음 시스템 프록시를 시작해 형식 오류를 네트워크 문제로 오해하지 않도록 하세요.

mixed-port: 7890
mode: rule

proxy-groups:
  - name: "프로토콜 선택"
    type: select
    proxies:
      - "VLESS-Reference"
      - "Hysteria2-Reference"
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,프로토콜 선택
  - MATCH,프로토콜 선택

이 설정은 정책 그룹과 규칙이 노드 이름을 어떻게 참조하는지 보여 줍니다. 참조 이름은 대소문자와 공백을 포함해 proxies에 있는 이름과 완전히 일치해야 합니다. 노드 이름을 바꾸면 정책 그룹의 기존 이름은 작동하지 않습니다. 실제 설정에는 보통 DNS, 규칙 프로바이더, 더 많은 정책 그룹도 포함되지만 문제를 해결할 때는 최소 구조로 줄여 노드 하나가 연결되는지 확인한 뒤 나머지를 단계적으로 복원할 수 있습니다. 출처를 모르는 설정을 통째로 복사하면 여러 변수가 동시에 추가되어 문제 위치를 판단하기 어려워집니다.

구독 변환의 한계

변환 도구는 한 컨테이너 형식을 다른 형식으로 바꿀 수 있지만 서버 파라미터를 없는 상태에서 채우거나 프로토콜 자체를 다른 프로토콜로 바꿀 수는 없습니다. 가능한 작업은 필드 매핑, 정책 그룹 생성, 노드 필터링, 이름 조정입니다. 최신 프로토콜이나 확장 전송 지원 여부는 변환기 구현에 달려 있습니다. 변환기가 필드를 인식하지 못하면 원본 구독이 올바르더라도 출력이 불완전할 수 있습니다. VLESS REALITY, Hysteria2, TUIC을 다룰 때는 서버가 직접 제공하는 mihomo 형식을 우선 사용하고 업데이트 후 핵심 필드를 확인하세요.

구독이 비어 있거나 형식을 인식하지 못하거나 업데이트에 실패하면 먼저 자주 묻는 질문의 설치 및 설정 항목을 확인하세요. 점검 순서는 주소 접근 가능 여부, 응답 내용, 형식 해석 가능 여부, 커널의 프로토콜 지원, 핵심 필드 완전성, 정책 그룹 편입, 연결 로그 순으로 유지해야 합니다. 이 순서대로 단계별 확인을 진행하는 편이 클라이언트를 반복해서 삭제하고 재설치하는 것보다 원인을 찾기 쉽습니다.