Clash 문제 해결 가이드: 연결·구독·DNS·TUN

인터넷 연결 안 됨: 기본 네트워크 상태 확인

인터넷 연결 문제는 Wi-Fi, 시스템 라우팅, 로컬 프록시, 규칙 선택, 원격 출구 등 어느 계층에서든 발생할 수 있습니다. 먼저 클라이언트 이름, 운영체제, 현재 모드와 장애가 모든 앱에서 발생하는지 특정 웹사이트에서만 발생하는지 기록하세요. 사용 중인 설정을 복사해 보관하고, 화면을 캡처할 때는 구독 주소·비밀번호·연결 정보를 가리세요. 클라이언트 업데이트, 네트워크 초기화, 구독 변경을 한꺼번에 하지 마세요. 연결이 복구되더라도 어떤 조치가 효과가 있었는지 알기 어렵습니다.

프록시를 끄고 기본 네트워크부터 테스트

클라이언트에서 ‘시스템 프록시’와 ‘TUN 모드’를 끈 다음 정상적으로 종료하세요. 시스템 네트워크 설정에 로컬 주소를 가리키는 수동 프록시가 남아 있지 않은지 확인하고, 모바일에서는 VPN 연결을 해제하세요. 평소 직접 연결되는 HTTPS 사이트에 접속하고 라우터 관리 페이지도 열리는지 확인합니다. 여전히 인터넷에 연결되지 않으면 Wi-Fi 인증, 게이트웨이, 광대역 연결 또는 공용 네트워크 로그인 페이지부터 해결하세요. 기본 네트워크가 복구되기 전에는 노드를 바꿔도 결과가 달라지지 않는 경우가 많습니다.

공용 Wi-Fi는 웹 인증이 필요한 경우가 많습니다. VPN을 끄고 시스템 안내에 따라 인증한 다음 클라이언트를 다시 연결하세요. 기기 한 대에서만 문제가 발생하면 같은 네트워크의 다른 기기와 비교하고, 모든 기기에서 문제가 발생하면 라우터와 상위 네트워크를 먼저 점검하세요. 비교를 위해 휴대폰 핫스팟으로 잠시 전환할 수도 있습니다. 핫스팟에서 연결된다고 해서 구독이 만료됐다는 뜻은 아닙니다. 두 네트워크의 차이를 기록한 뒤 DNS, UDP 또는 방화벽 제한을 확인하세요.

로컬 프록시 연결과 실제 외부 연결 확인

클라이언트를 다시 시작하고 정상적으로 불러온 설정을 선택하세요. TUN은 끈 상태로 두고 시스템 프록시만 켭니다. ‘설정’에서 실제 HTTP 또는 혼합 프록시 포트를 확인한 뒤 명시적 프록시 요청을 테스트하세요. 아래 명령은 클라이언트 포트가 실제로 7890일 때만 사용할 수 있습니다. 화면에 다른 포트가 표시되면 함께 수정하세요. Windows PowerShell에서는 별칭 때문에 매개변수 해석이 달라지지 않도록 curl.exe를 사용하세요. 테스트 주소는 점검 중인 웹사이트로 바꿔도 됩니다.

# Windows PowerShell
curl.exe -I --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:7890 https://example.com/

# macOS / Linux
curl -I --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:7890 https://example.com/

즉시 ‘연결 거부’가 발생하면 로컬 포트에서 수신 대기 중인 프로세스가 없거나, 포트가 잘못됐거나, 커널이 시작되지 않았을 가능성이 큽니다. 먼저 원격 노드 문제로 단정하지 마세요. 로컬 프록시에는 연결되지만 이후 시간 초과가 발생하면 클라이언트의 ‘연결’과 ‘로그’를 확인하세요. 로그에 DIRECT로 표시되면 규칙과 대상 도메인이 예상대로 처리되는지 점검합니다. 프록시 정책 그룹에 연결됐다면 실제로 선택된 출구를 확인하세요. 화면에 표시된 설정 이름과 현재 사용 중인 설정이 다를 수 있으므로, 가져오기에 성공한 뒤에도 활성화 여부를 확인해야 합니다.

범위를 좁힌 뒤 평소 설정으로 복구

필요한 경우에만 잠시 ‘전역’ 모드로 바꾸고 같은 대상을 다시 테스트하세요. 전역 모드에서는 연결되지만 규칙 모드에서 실패하면 규칙 순서, 정책 그룹 이름, 마지막 기본 규칙을 확인합니다. 두 모드 모두 실패하면 노드 시간 초과 섹션으로 이동하세요. 전역 모드라고 해서 모든 앱의 트래픽이 프록시를 통과하는 것은 아닙니다. 시스템 프록시 설정을 읽지 않는 프로그램은 직접 연결될 수 있습니다. 모드와 TUN 설정을 동시에 변경하면 규칙 문제인지 트래픽 가로채기 문제인지 구분하기 어렵습니다.

클라이언트를 종료해도 인터넷이 끊겨 있다면 시스템에 남은 로컬 프록시를 지우고, 다른 VPN·가상 네트워크 어댑터·보안 소프트웨어가 라우팅을 가로채는지 확인하세요. 모든 네트워크 어댑터를 삭제하거나 방화벽을 통째로 초기화하지 마세요. 관련 프로그램을 먼저 중지하고 시스템을 재부팅한 뒤 어떤 조치로 네트워크가 복구됐는지 확인하세요. 원인을 찾지 못했다면 오류가 발생한 시간과 첫 번째 오류 로그를 보관하고 다음 섹션에서 계속 확인하세요.

노드 시간 초과: 탐색 테스트와 실제 연결 구분

클라이언트의 시간 초과는 지정된 시간 안에 특정 탐색이 완료되지 않았다는 뜻이지, 해당 출구가 모든 대상에서 작동하지 않는다는 뜻은 아닙니다. 탐색 과정에는 도메인 조회, 연결 설정, 프로토콜 핸드셰이크, 테스트 주소의 응답이 포함됩니다. 어느 단계에서든 실패하면 시간 초과로 표시될 수 있습니다. 먼저 출구 하나를 선택해 대상 웹사이트에 직접 접속하고 로그의 오류와 비교하세요. 그룹 전체를 연달아 테스트하지 마세요. 동시 탐색이 많으면 서버 제한을 유발하고 로컬 네트워크 부하 때문에 원래 문제를 파악하기 어려워질 수 있습니다.

오류 발생 단계에 따라 분류

‘로그’를 열고 로그 수준을 잠시 info로 설정한 다음 기존 기록을 지우고 요청을 한 번 실행하세요. 더 자세한 정보가 필요하면 debug를 짧게 사용합니다. 마지막에 표시된 ‘요청 실패’만 보지 말고 대상 요청과 관련된 첫 오류를 찾으세요. 연결 시간 초과는 네트워크에 도달할 수 없거나 포트가 차단됐을 가능성이 있습니다. 연결 거부는 대상 서버가 연결을 거부했을 때 주로 발생합니다. TLS 핸드셰이크 오류는 서버 이름, 시스템 시간 또는 인증서 문제와 관련될 수 있습니다. 오류 문구는 단서일 뿐, 한 줄만으로 원인을 확정할 수는 없습니다.

노드 서버 도메인을 조회하는 단계에서 오류가 발생하면 DNS 문제 섹션에서 부트스트랩 조회를 확인하세요. 도메인은 조회됐지만 서버 포트에 연결할 수 없다면 Windows에서 다음 명령으로 TCP 연결을 테스트할 수 있습니다. 서버 이름과 포트는 현재 설정에서 확인하세요. 명령의 도메인은 예시입니다. 이 테스트는 TCP 연결 여부만 확인하며 프록시 프로토콜 인증 성공을 증명하지는 않습니다. UDP 기반 프로토콜의 정상 여부를 판단하는 용도로도 사용할 수 없습니다.

# 도메인과 포트를 현재 출구의 실제 설정으로 바꾸세요
Test-NetConnection -ComputerName proxy.example.com -Port 443

프로토콜 매개변수와 시스템 시간 확인

구독에서 가져온 출구는 우선 다시 업데이트하고, 설정을 하나씩 추측해 바꾸지 마세요. 직접 설정한 경우 서버 주소, 포트, 비밀번호 또는 사용자 ID와 전송 계층, 경로, 서버 이름 등의 매개변수를 확인합니다. 이름이 비슷한 프로토콜도 서로 호환되지 않으며, 오래된 커널은 새 필드를 인식하지 못할 수 있습니다. 설정 로드 로그에서 ‘지원하지 않는 유형’ 또는 필드 구문 분석 오류가 있는지 확인한 뒤 클라이언트 업데이트 여부를 결정하세요. 업데이트는 클라이언트 다운로드 페이지에서 진행하고, 서로 다른 클라이언트의 데이터 디렉터리를 덮어쓰지 마세요.

HTTPS 대상과 TLS를 사용하는 프록시 연결은 시스템 시간의 영향을 받습니다. 시스템의 ‘날짜 및 시간’ 설정에서 자동 동기화를 켜고 시간대가 올바른지 확인하세요. 인증서 오류를 해결하려고 인증서 검증을 계속 끄지 마세요. 먼저 구독 제공업체가 요구하는 서버 이름과 인증서 설정을 확인해야 합니다. 회사 네트워크의 HTTPS 검사, 만료된 인증서 또는 잘못된 도메인도 핸드셰이크 오류를 일으킬 수 있습니다. 사무실 네트워크에서만 실패하고 핫스팟에서는 정상이라면 보안 설정을 계속 낮추는 대신 네트워크 관리자에게 제한 여부를 문의하세요.

자동 정책 그룹의 탐색 조건 확인

url-test는 설정된 테스트 주소로 후보 출구를 평가하고, fallback은 사용 가능 여부와 순서에 따라 출구를 전환합니다. 두 방식 모두 탐색이 완료되어야 작동합니다. 테스트 주소에 접근할 수 없거나 응답 방식이 바뀌었거나 현재 네트워크에 적합하지 않으면 실제로 쓸 수 있는 출구가 비정상으로 표시될 수 있습니다. 아래는 필드 구성 예시일 뿐이므로 기존 정책 그룹에 실제 후보 목록을 유지해 적용하세요. 후보 목록이 비어 있으면 프록시 그룹으로 사용할 수 없습니다.

proxy-groups:
  - name: 자동 선택
    type: url-test
    proxies:
      - DIRECT
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

예시의 DIRECT는 구조와 직접 연결 탐색을 설명하기 위한 값일 뿐입니다. 실제 프록시를 선택하려면 설정에 이미 있는 출구 이름으로 바꾸세요. interval은 테스트 간격(초)이며 연결 시간 초과가 아닙니다. tolerance는 전환 허용 범위로, 연결할 수 없는 서버를 복구해 주지 않습니다. 수동으로 선택한 출구는 정상인데 자동 그룹에서 계속 문제가 발생한다면 탐색 대상과 그룹 참조를 확인한 다음 정책 그룹 유형 비교를 참고하세요.

마지막으로 한 번에 한 변수씩 비교하세요. 같은 출구에서 네트워크를 바꾸고, 같은 네트워크에서 출구를 바꾸고, 같은 출구에서 대상 웹사이트를 바꿔 테스트합니다. 한 대상에서만 실패하면 해당 대상의 규칙이나 서비스 제한을 확인해야 할 수 있습니다. 같은 네트워크에서 모든 출구가 실패하면 로컬 방화벽, 시스템 시간, 네트워크 제한을 다시 확인하세요. 시간 초과 값을 계속 늘리기보다 안정적으로 작동하는 비교 결과를 확보하는 편이 원인 파악에 도움이 됩니다. 변경 후 실제 요청을 다시 테스트하고, 화면의 탐색 색상만으로 복구 여부를 판단하지 마세요.

구독 오류: 다운로드와 설정 파싱 확인

구독 업데이트는 두 단계로 진행됩니다. 먼저 네트워크에서 응답을 가져오고, 그다음 응답을 설정 또는 출구 목록으로 파싱합니다. ‘다운로드 실패’와 ‘설정이 유효하지 않음’은 점검 방향이 다릅니다. 구독 카드나 로그에서 전체 오류를 확인하고 HTTP 상태 코드, 파싱 메시지, 발생 시간을 기록하세요. 구독 링크에는 접근 인증 정보가 포함되는 경우가 많으므로 포럼, 스크린샷 또는 온라인 변환 도구에 올리지 마세요. 도움을 요청할 때는 원본 링크를 보내지 말고 도메인 유형, 오류 코드와 민감 정보를 제거한 구조만 공유하세요.

주소와 계정 상태 확인

구독 제공업체 페이지에서 전체 링크를 다시 복사하고, 올바른 HTTPS 주소로 시작하는지와 끝부분 매개변수가 메신저에서 잘리지 않았는지 확인하세요. 복사할 때 한글 문장부호, 줄바꿈, 공백이 섞이지 않도록 주의하세요. 로그인 주소, 공유 페이지 주소, 구독 API 주소는 서로 다릅니다. 계정 페이지가 열려도 해당 주소가 클라이언트 설정을 반환한다는 뜻은 아닙니다. 링크가 재발급됐다면 클라이언트에 저장된 이전 링크는 계속 접근 거부 응답을 반환할 수 있습니다.

401 또는 403 오류가 발생하면 계정 권한, 구독 유효 상태, API 접근 조건을 먼저 확인하세요. 404 오류는 경로가 변경됐는지 확인합니다. 429 오류가 발생하면 반복 재시도를 중단하고 제공업체 안내에 따라 기다리세요. 서버 오류는 상위 서비스의 일시적인 문제일 수 있으므로 설정을 계속 삭제하지 마세요. 일부 API는 요청 클라이언트에 따라 다른 형식으로 응답합니다. 파일 확장자만 보고 판단하지 말고 제공업체가 명시한 Clash 또는 mihomo 호환 구독을 선택하세요.

다운로드 과정과 콘텐츠 형식 분리

현재 출구가 작동하지 않고 구독 업데이트도 해당 출구를 통해 실행되도록 설정돼 있다면, ‘연결하려면 업데이트가 필요하고 업데이트하려면 연결이 필요한’ 상황이 생길 수 있습니다. 구독 업데이트 설정에서 직접 연결, 시스템 네트워크, 프록시 중 무엇을 사용하는지 확인하세요. 가능하다면 정상 작동하는 다른 네트워크로 업데이트하세요. 클라이언트에 따라 구독 다운로드를 화면 프로세스가 처리하기도 하고 커널이 처리하기도 합니다. 따라서 브라우저에서 접속된다고 해서 클라이언트 요청도 같은 방식으로 처리된다고 볼 수는 없습니다. 먼저 로그를 확인한 뒤 업데이트 경로를 조정하세요.

응답이 로그인 페이지, CAPTCHA 페이지 또는 게이트웨이 안내라면 클라이언트가 HTML을 설정 파일로 파싱해 첫 줄 구문 오류가 발생할 수 있습니다. 메시지를 없애려고 첫 줄을 삭제하지 마세요. 응답을 확인해야 한다면 로컬에 저장해 텍스트 편집기로 앞부분 구조를 확인하고 공개 웹사이트에는 업로드하지 마세요. 유효한 YAML이어도 완전한 설정 파일이 아닐 수 있습니다. 출구 목록만 포함된 콘텐츠는 proxy-providers에서 참조해야 하며 항상 기본 설정으로 바로 활성화할 수 있는 것은 아닙니다.

증상	우선 확인	조치
요청 시간 초과	업데이트 경로, 도메인 조회	정상 네트워크로 전환하고 구독 요청이 작동하지 않는 프록시를 거치는지 확인
접근 거부	권한 및 링크 상태	유효한 주소를 다시 발급받고 제공업체 안내 확인
YAML 파싱 오류	응답 콘텐츠 및 들여쓰기	웹페이지 응답이 아닌지 확인하고 오류 줄 주변 구조를 보존
알 수 없는 프록시 유형	커널 호환성	해당 프로토콜을 지원하는 클라이언트와 커널 사용

구문을 수정하고 기존 설정 보존

YAML을 직접 수정할 때는 공백으로 들여쓰고 탭을 사용하지 마세요. 특수 문자가 포함된 비밀번호나 주소는 적절한 따옴표로 감싸야 합니다. 오류 줄 번호는 파서가 더 이상 진행할 수 없게 된 위치를 가리킬 수 있으며 실제 문제는 앞줄의 콜론, 따옴표 또는 목록 계층에 있을 수 있습니다. 먼저 복사본을 내보낸 뒤 관련 부분만 수정하세요. 온라인에서 찾은 전체 설정을 구독 파일에 덮어쓰지 마세요. 구독 업데이트 시 해당 파일이 덮어써져 임시 수정 내용을 추적하기 어렵고 잃어버릴 수도 있습니다.

구독 다운로드는 성공했지만 선택할 출구가 없다면 계정이 실제로 유효한 콘텐츠를 반환하는지, 필터 표현식이 모든 항목을 제외했는지 확인하세요. 로그에 정책 그룹이 존재하지 않는 이름을 참조한다고 표시되면 로컬 오버라이드, 구독 이름 변경, 그룹 내 참조를 점검합니다. 최근 추가한 오버라이드나 병합 스크립트를 잠시 끄고 원본 구독을 다시 불러오세요. 원본 설정이 정상이라면 항목을 하나씩 복원합니다. 기본 가져오기 절차를 다시 확인하려면 구독 가져오기 가이드를 참고하세요.

속도 저하: 응답 시간과 전송 속도 구분

웹페이지 첫 화면 지연, 다운로드 속도 저하, 동영상 끊김, 음성 끊김은 서로 다른 문제입니다. 웹페이지는 DNS 조회와 핸드셰이크, 여러 리소스 요청의 영향을 크게 받습니다. 대용량 파일은 지속 전송 속도가 중요하고 실시간 앱은 패킷 손실과 지터에도 영향을 받습니다. 어떤 앱과 대상에서 어느 시간대에 느린지, 직접 연결할 때도 같은지 먼저 기록하세요. 정책 그룹 탐색 결과만으로 다운로드 속도를 판단하지 마세요. 짧은 요청에 빠르게 응답하는 출구가 지속 전송에도 빠르다는 보장은 없습니다.

조건을 맞춰 비교 테스트

같은 기기, 같은 네트워크, 같은 대상을 유지한 상태에서 직접 연결과 수동으로 선택한 출구 하나를 각각 테스트하세요. 클라우드 동기화, 시스템 업데이트, 기타 대용량 작업을 잠시 중지해 백그라운드 전송의 영향을 줄입니다. Wi-Fi를 사용할 때는 먼저 라우터 가까이에서 테스트하고, 필요하면 유선 연결과 비교하세요. 로컬 네트워크 전송도 느리면 신호, 무선 간섭, 네트워크 어댑터를 우선 확인합니다. 특정 원격 사이트만 느리다면 대상 서비스, 네트워크 간 경로 또는 해당 사이트의 접속 출구 제한과 관련이 있을 수 있습니다.

여러 번 테스트할 때는 조건을 비슷하게 유지하세요. 서로 다른 웹사이트, 파일, 시간대의 결과를 비교하면 정확하지 않습니다. 브라우저 캐시 때문에 두 번째 접속이 훨씬 빨라질 수 있고, 다운로드 사이트가 서버를 동적으로 배정할 수도 있습니다. 브라우저 개발자 도구의 ‘네트워크’ 패널에서 첫 바이트 대기, 연결 설정, 콘텐츠 다운로드에 각각 얼마나 걸리는지 확인하세요. 첫 바이트 대기 시간이 길다고 반드시 대역폭이 부족한 것은 아닙니다. 서버 처리, 우회 경로 또는 연결 재시도가 원인일 수 있습니다.

트래픽 분기와 앱 연결 동작 확인

클라이언트의 ‘연결’을 열고 대상 도메인이나 프로세스로 필터링해 느린 요청에 적용된 규칙과 실제 출구를 확인하세요. 한 페이지에서 이미지, 스크립트, API를 함께 요청할 수 있으므로 기본 도메인만 확인하면 특정 리소스의 문제를 놓칠 수 있습니다. 광고 차단, 브라우저 확장 프로그램, 보안 소프트웨어가 리소스를 차단해 페이지가 계속 기다리는 것처럼 보일 수도 있습니다. 새 브라우저 프로필을 사용하거나 관련 확장 프로그램을 잠시 끄고 비교하세요. 원인을 찾기 전에 규칙 전체를 변경하지 마세요.

자동 정책 그룹이 자주 전환되면 앱이 다시 연결될 수 있으며, 지속 다운로드나 연결 시간이 긴 작업에서 더욱 두드러집니다. 문제를 확인할 때는 먼저 작동하는 출구 하나를 고정해 증상이 사라지는지 살펴본 다음 테스트 간격이나 전환 허용 범위를 조정하세요. ‘실시간 최적화’를 위해 간격을 지나치게 짧게 설정하지 마세요. 탐색에도 연결과 트래픽이 사용됩니다. 정책 그룹별 동작은 url-test, fallback, load-balance 설명을 참고하세요.

UDP, MTU, 동시 연결은 신중하게 확인

동영상이나 실시간 통신만 실패하고 일반 웹페이지는 정상이라면 앱이 UDP를 사용하는지, 현재 프로토콜·출구 설정·서버가 해당 트래픽을 지원하는지 확인하세요. 브라우저의 HTTP/3도 UDP를 사용하며 일부 제한된 네트워크에서는 여러 차례 시도한 뒤 다른 방식으로 전환될 수 있습니다. 비교를 위해 앱의 관련 기능을 잠시 끌 수는 있지만, 모든 UDP를 비활성화해야 한다고 단정하면 안 됩니다. 음성 통화, 게임, 일부 터널 프로토콜은 UDP가 필요하므로 계속 끄면 다른 문제가 생길 수 있습니다.

TUN 모드에서만 대용량 파일이 멈추고 작은 요청은 정상이라면 경로 MTU 문제인지 추가로 확인하세요. 다른 VPN이 동시에 실행 중이지 않은지 먼저 확인한 다음, 클라이언트가 허용하는 범위에서 TUN MTU를 조금씩 낮추세요. 한 번에 하나의 값만 바꾸고 연결을 다시 설정합니다. 모든 네트워크에 맞는 고정 최적값은 없습니다. 안정적인 개선이 없다면 원래 값으로 되돌려 임시 우회 설정이 영구 설정으로 남지 않게 하세요. MTU 테스트 결과는 시스템과 링크 유형의 영향을 받으므로 명령 하나의 결과를 그대로 일반화하지 마세요.

마지막으로 기기 리소스 상태를 확인하세요. 클라이언트가 오랫동안 과도한 리소스를 사용한다면 디버그 로그가 많이 쌓였는지, 중복 규칙을 불러왔는지, 커널 여러 개가 동시에 실행 중인지 확인합니다. 디스크 공간이 부족해도 로그 기록이 느려질 수 있습니다. 디버그 로그를 끄고 중복 작업을 줄인 뒤 다시 테스트하세요. 네트워크나 출구를 바꿨을 때 안정적으로 개선된다면 비교 결과를 기록하세요. 모든 경로에서 특정 대상만 느리다면 로컬 소프트웨어 손상으로 단정하지 말고 대상 서비스 또는 구독 제공업체에 문의하세요.

DNS 문제: 이름 조회 경로 파악

DNS 문제는 도메인 접속 실패, 첫 연결 지연, 로컬 네트워크 기기 이름 조회 실패 또는 로그의 DNS 시간 초과로 나타날 수 있습니다. 세 가지 경로를 구분하세요. 시스템이 일반 도메인을 조회하는 방법, 커널이 대상 도메인을 조회하는 방법, 프록시 서버 자체의 도메인을 조회하는 방법입니다. 각 경로를 처리하는 구성 요소가 다를 수 있습니다. 특정 IP 주소로 접속된다고 HTTPS 서비스도 정상이라는 뜻은 아닙니다. 인증서와 가상 호스트에는 도메인이 필요하므로 IP 접속을 최종 해결책으로 사용하지 마세요.

요청을 처리하는 DNS 확인

시스템에서 현재 네트워크 인터페이스의 DNS 설정을 확인하고 아래 명령으로 기본 조회 결과를 확인하세요. 명령 결과는 시스템 조회 경로를 보여 주며 브라우저의 보안 DNS나 커널 내부 조회와 같지 않을 수 있습니다. 브라우저에서 암호화 DNS를 사용하면 시스템 DNS를 우회할 수 있습니다. TUN에서 DNS 하이재킹을 사용한다면 일반 조회가 커널에 의해 처리될 수도 있습니다. 테스트 전에 해당 기능을 켰는지 기록하세요. 그래야 서로 다른 도구의 결과를 직접 비교하는 오류를 피할 수 있습니다.

# Windows
nslookup example.com
ipconfig /flushdns

# macOS / Linux: dig 설치 시 사용
dig example.com A
dig example.com AAAA

캐시를 지우면 오래된 결과만 제거할 수 있으며, 연결할 수 없는 상위 DNS 서버나 잘못된 설정은 고쳐지지 않습니다. 먼저 조회 경로를 조정한 다음 시스템과 앱의 캐시를 지우고 다시 연결하세요. 조회 결과가 NXDOMAIN이면 해당 이름을 찾지 못했다는 뜻이지만, 도메인 자체가 없는 것인지 상위 서버 응답에 문제가 있는지는 추가 확인이 필요합니다. 조회 시간 초과는 경로나 서비스 문제일 가능성이 더 큽니다. 모든 실패를 ‘DNS 캐시 오염’으로 단정하지 말고, DNS 서버마다 다른 IP를 반환한다는 이유만으로 한쪽이 잘못됐다고 판단하지 마세요.

fake-ip와 부트스트랩 조회 이해

fake-ip는 앱에 내부 매핑에 사용할 주소를 반환하고, 이후 커널이 매핑 정보를 통해 실제 도메인과 연결합니다. 설정에 따라 198.18.0.0/16 범위의 주소가 표시되는 것은 정상일 수 있으며 대상 웹사이트가 실제로 그 주소에 배포됐다는 뜻은 아닙니다. 앱에 이전 매핑이 남아 있는데 커널이 이미 재시작됐다면 연결에 실패할 수 있습니다. 영향을 받은 앱을 종료했다가 다시 실행한 뒤 클라이언트에서 지원하는 방법으로 DNS 매핑을 지우세요. 매핑을 우회하려고 해당 주소 범위 전체를 직접 연결 규칙에 추가하지 마세요.

프록시 서버의 도메인은 프록시가 연결되기 전에 조회할 수 있어야 합니다. 그렇지 않으면 시작 과정에서 의존성 순환이 발생합니다. mihomo의 proxy-server-nameserver는 이러한 도메인에 사용할 DNS 서버를 지정합니다. default-nameserver는 DNS 상위 서버 자체의 도메인을 조회하는 데 사용됩니다. 아래 설정 조각은 의존 관계를 보여 주는 예시일 뿐입니다. 사용 전 현재 네트워크에서 DNS 서버에 연결할 수 있는지 확인하세요. 기존 클라이언트 설정과 충돌하도록 별도의 DNS 수신 포트를 열거나 구독 설정 전체를 교체하지 마세요.

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  proxy-server-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query

로컬 네트워크 도메인과 IPv4·IPv6 차이 처리

회사 인트라넷, 가정용 저장 장치, 라우터 이름은 대개 내부 DNS에 의존합니다. 모든 조회를 공개 DNS 서버로 보내면 이런 이름을 찾지 못할 수 있습니다. 로컬 네트워크 기기에서 원래 사용하던 DNS 서버를 확인한 뒤 nameserver-policy로 지정된 내부 도메인 접미사의 조회 경로를 지정하세요. fake-ip 호환 문제가 있다면 필요한 도메인만 필터링할 수 있습니다. 하지만 필터링만으로 공개 DNS가 내부 레코드를 조회할 수 있게 되지는 않습니다. 해당 이름에 응답할 수 있는 상위 DNS 서버를 설정해야 합니다.

IPv4는 정상이지만 IPv6 경로가 불완전하면 앱이 IPv6 연결을 먼저 시도한 뒤 시간이 지나서야 다른 경로로 전환될 수 있습니다. A와 AAAA 레코드를 각각 확인하고 로그에서 실제로 연결한 주소 유형을 살펴보세요. 비교를 위해 클라이언트의 IPv6 조회 옵션을 잠시 끌 수 있지만, 시스템에서 IPv6를 영구적으로 비활성화해야 한다고 단정하지 마세요. 일부 네트워크는 완전한 연결을 위해 IPv6가 필요합니다. 원인을 파악한 뒤 라우팅이나 출구 지원을 수정하고 필요한 듀얼 스택 설정을 복원하세요.

수정 후에는 공개 웹사이트, 노드 도메인, 자주 사용하는 로컬 네트워크 서비스까지 모두 테스트하세요. 공개 웹페이지는 복구됐지만 프린터나 내부 시스템에 연결할 수 없다면 완전히 해결된 것이 아닙니다. 규칙과 DNS의 관계는 규칙 기반 라우팅 실전 가이드를 참고하세요. 용어가 헷갈리면 개념 빠른 확인에서 각 필드가 경로의 어느 부분을 담당하는지 확인한 뒤 변경 여부를 결정하세요.

시스템 프록시가 작동하지 않음: 앱 연결 경로별 점검

‘시스템 프록시’는 운영체제에 프록시 주소를 등록하는 기능이며, 해당 설정을 읽는 앱만 사용합니다. TUN은 가상 네트워크 인터페이스를 통해 라우팅 조건에 맞는 트래픽을 가져옵니다. 두 기능은 서로 다른 계층에서 작동합니다. 브라우저는 정상인데 터미널은 직접 연결된다고 해서 반드시 클라이언트 문제인 것은 아닙니다. 게임이나 별도 다운로드 프로그램도 자체 연결 설정을 사용할 수 있습니다. 먼저 명시적 프록시 요청이 성공하는지 확인한 다음 앱 연결 설정을 고칠지 TUN을 켤지 결정하세요. 모든 상황을 노드 문제로 단정하지 마세요.

브라우저·터미널·서비스별 확인

브라우저 프록시 확장 프로그램이 시스템 설정을 덮어쓰는지 확인하고, 프록시 관리 기능이 중복으로 켜져 있다면 끈 뒤 브라우저를 다시 시작하세요. Firefox 등 일부 프로그램은 별도의 프록시 설정을 사용하므로 시스템 프록시를 사용하도록 설정했는지 또는 올바른 로컬 포트를 입력했는지 확인합니다. 그런 다음 클라이언트의 ‘연결’을 열고 대상 웹사이트에 접속해 요청이 표시되는지 확인하세요. 화면에 기록이 없다고 해서 확정할 수는 없지만, 명시적 프록시 요청이 성공한다면 앱 설정을 중점적으로 살펴볼 수 있습니다.

터미널 도구가 환경 변수를 읽는지는 프로그램마다 다릅니다. 아래 설정은 현재 터미널과 이후에 실행되는 하위 프로세스에만 적용됩니다. 이미 실행 중인 프로그램에는 새 환경이 자동으로 반영되지 않습니다. 포트를 클라이언트의 실제 값으로 바꾸고 같은 대상으로 테스트하세요. NO_PROXY는 프록시를 우회할 대상을 지정하며 도메인 범위를 지나치게 넓게 설정하지 마세요. 테스트가 끝나면 임시 변수를 삭제하세요. 클라이언트를 종료한 뒤에도 터미널이 존재하지 않는 로컬 포트에 연결하려는 상황을 막을 수 있습니다.

# PowerShell: 현재 세션
$env:HTTP_PROXY = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"
$env:NO_PROXY = "localhost,127.0.0.1,::1"
curl.exe -I https://example.com/

# 현재 세션의 임시 설정 삭제
Remove-Item Env:HTTP_PROXY, Env:HTTPS_PROXY, Env:NO_PROXY -ErrorAction SilentlyContinue

# macOS / Linux: 이 명령에만 적용
https_proxy=http://127.0.0.1:7890 curl -I https://example.com/

HTTPS 대상에 사용하는 프록시 주소가 http://로 시작하더라도 이는 로컬 프록시에 연결하는 방식을 뜻하며 대상 웹사이트를 평문으로 낮추는 것은 아닙니다. SOCKS 포트와 HTTP 포트를 임의로 바꿔 쓸 수 없습니다. socks5h를 사용하는 도구는 대상 도메인의 조회를 프록시에 맡기는 경우가 많아 로컬 DNS 문제를 구분할 때 유용합니다. 백그라운드 서비스, 컨테이너, 원격 세션은 별도의 환경을 사용합니다. 호스트 컴퓨터의 브라우저가 정상이라고 해서 이들이 같은 설정을 상속하는 것은 아닙니다.

TUN 시작 후 권한과 라우팅 확인

시스템 프록시를 읽지 않는 앱의 트래픽을 가져와야 할 때는 클라이언트 안내에 따라 서비스 구성 요소를 설치하거나 활성화한 뒤 TUN을 켜세요. 스위치가 즉시 꺼진다면 로그에서 권한, 네트워크 장치 생성, 라우팅 오류를 확인합니다. Windows의 서비스 모드, macOS의 시스템 권한, Linux의 네트워크 관리 권한은 서로 다른 방식이므로 한 플랫폼의 절차를 다른 플랫폼에 그대로 적용하지 마세요. 우선 선택지로 Clash Plus를 고려할 수 있습니다. 다른 클라이언트의 화면 구성과 시스템 요구 사항은 다운로드 페이지를 참고하세요.

TUN이 켜져 있는데도 트래픽이 통과하지 않으면 다른 VPN, 가상 머신 네트워크, 수동 고정 경로, 앱 제외 규칙이 있는지 확인하세요. 아래는 mihomo에서 자주 사용하는 필드 예시입니다. 클라이언트가 지원하는 오버라이드 방식으로 병합해 화면에서 자동 생성한 TUN 설정과 중복되지 않도록 하세요. auto-route는 경로를 자동 설정하고 auto-detect-interface는 출구 인터페이스 선택을 돕습니다. 두 필드 모두 필요한 시스템 권한을 대신하지 않으며 복잡한 모든 네트워크를 자동으로 올바르게 인식한다고 보장하지 않습니다.

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

로컬 네트워크 경로 유지 및 남은 설정 정리

TUN을 켠 뒤 로컬 네트워크가 작동하지 않으면 내부 네트워크 대역이 잘못 가로채졌는지, 내부 도메인이 올바른 DNS 서버로 전달되는지 먼저 확인하세요. 라우팅 제외와 규칙의 직접 연결은 서로 다른 작업입니다. 전자는 트래픽이 터널로 들어가는지 결정하고, 후자는 커널에 들어온 트래픽의 출구를 결정합니다. 업무 요구 사항을 확인한 뒤 필요한 네트워크 대역만 정확히 설정하세요. 지나치게 넓은 제외 범위로 모든 트래픽을 우회하지 마세요. 사내 VPN에 전용 경로가 있다면 조직의 네트워크 정책을 우선해야 합니다.

점검이 끝나면 TUN을 먼저 끄고 시스템 프록시를 해제한 뒤 클라이언트를 정상 종료해 직접 연결이 복구되는지 확인하세요. 비정상 종료로 프록시 설정이 남았다면 시스템 네트워크 설정에서 해당 주소를 지우면 됩니다. 클라이언트를 바로 삭제할 필요는 없습니다. 브라우저와 터미널을 확인하는 전체 순서는 시스템 프록시가 작동하지 않을 때 확인할 사항을 참고하세요. 라우터 배포가 목적이라면 OpenWrt 바이패스 라우터 배포 요령을 확인하고 데스크톱 시스템 프록시 안내를 그대로 적용하지 마세요.

클라이언트 충돌: 화면과 커널 문제 분리

창이 닫히는 현상, 트레이 아이콘이 사라지는 현상, 커널 중지, 설정 로드 실패는 서로 다른 상태입니다. 클라이언트가 백그라운드에서 실행 중인지, 시스템 프록시가 여전히 해당 클라이언트를 가리키는지, 로그가 계속 생성되는지 먼저 확인하세요. 화면은 열리지 않는데 프록시가 작동한다면 화면 프로세스 문제일 수 있습니다. 창은 정상인데 모든 요청이 실패한다면 커널이 시작되지 않았을 가능성이 있습니다. 프로그램을 반복해서 실행하면 프로세스 중복과 포트 충돌이 생길 수 있으므로 먼저 작업 관리자나 시스템 활동 모니터에서 실행 중인 인스턴스를 확인한 뒤 재시작하세요.

복구에 필요한 기록과 데이터부터 보관

장애 직전 마지막으로 수행한 작업을 기록하세요. 구독 업데이트, 오버라이드 추가, TUN 활성화, 규칙 가져오기, 클라이언트 업데이트 등이 해당됩니다. ‘설정’의 로그 또는 설정 디렉터리 메뉴에서 관련 파일을 저장하세요. 디렉터리 위치는 클라이언트와 설치 방식에 따라 다르므로 다른 소프트웨어의 고정 경로를 그대로 따르지 마세요. 화면을 열 수 없다면 시스템 앱 로그나 충돌 보고서를 활용하세요. 외부에 공유하기 전 구독 링크, 비밀번호, 제어 인터페이스 인증 정보, 접속 기록이 노출될 수 있는 내용을 삭제하세요.

구독 원본, 사용자 오버라이드, 규칙 파일, 정책 선택 기록을 백업하세요. 생성 중인 런타임 설정만 복사하지 마세요. 캐시와 임시 필드가 섞여 있을 수 있고 다음 시작 때 실제로 읽는 원본 파일이 아닐 수도 있습니다. 데이터 디렉터리를 옮기기 전에는 프로그램을 종료해 데이터베이스나 파일을 기록하는 도중 잘리지 않도록 하세요. 복구 가능한 백업은 로컬의 안전한 디렉터리에 보관하고, 도움을 요청한다는 이유로 설정 디렉터리 전체를 공개하지 마세요.

시작 실패의 구체적인 원인 확인

로그에 주소가 이미 사용 중이라고 나오면 어떤 프로세스가 프록시 포트 또는 제어 인터페이스 포트에서 대기 중인지 확인하세요. 아래 명령은 7890 사용 여부를 확인하는 예시이므로 실제 설정에 맞춰 포트를 바꾸세요. 수신 대기 중인 프로세스를 찾으면 먼저 프로그램 이름을 확인하고 시스템 프로세스를 바로 종료하지 마세요. 기존 클라이언트가 백그라운드에서 실행 중이거나, 다른 커널을 동시에 시작했거나, 재시작 과정에서 잠시 중복 실행됐을 수 있습니다. 여러 포트를 무작정 바꾸기보다 명확한 인스턴스 하나만 사용하는 편이 관리하기 쉽습니다.

# Windows PowerShell
Get-NetTCPConnection -State Listen -LocalPort 7890 |
  Select-Object LocalAddress, LocalPort, OwningProcess

# macOS: 로컬 TCP 수신 대기 확인
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux: 수신 대기 포트 확인
ss -lntp

커널이 시작 직후 종료된다면 설정 파싱 오류, 규칙 파일 읽기 권한, 디스크 공간, 외부 리소스 로드 실패를 확인하세요. 최근 추가한 오버라이드나 규칙 제공자를 비활성화하고 이전에 정상 작동하던 설정을 다시 불러오세요. 특정 설정에서만 문제가 발생한다면 화면을 재설치하기보다 설정을 먼저 수정해야 합니다. 파일을 쓸 수 없다는 오류가 발생하면 설치 디렉터리와 데이터 디렉터리의 권한을 확인하세요. 문제를 피하려고 모든 파일을 모든 사용자가 쓸 수 있도록 변경하지 마세요.

창이 비어 있거나 화면 구성 요소 오류가 나타나면 클라이언트 문서에서 시스템 실행 구성 요소와 지원 운영체제 범위를 확인하세요. 보안 소프트웨어의 격리 기록도 살펴보고 어떤 파일이 차단됐는지와 사유를 확인해야 합니다. 전체 보안 기능을 장기간 끄는 방법으로 해결하지 마세요. 신뢰할 수 있는 출처에서 다시 다운로드하고 시스템 안내에 따라 권한을 부여할 수 있습니다. 설치 파일 아키텍처는 기기와 맞아야 합니다. 구형 운영체제는 최신 화면 구성 요소를 지원하지 않을 수 있으므로 호환성 정보는 다운로드 페이지와 프로젝트 안내를 기준으로 확인하세요.

데이터를 지우지 말고 격리 테스트

캐시나 로컬 상태 손상이 의심되면 클라이언트를 종료한 뒤 데이터 디렉터리의 이름을 바꿔 보관하세요. 프로그램이 문서에서 지원하는 방식으로 새 디렉터리를 만들도록 합니다. 새 환경에서 시작되면 구독과 사용자 오버라이드를 하나씩 가져와 문제를 일으키는 항목을 찾으세요. 기존 디렉터리를 바로 삭제하거나 캐시 전체를 한꺼번에 복사하지 마세요. 포터블 모드와 설치 모드를 함께 사용한다면 두 모드가 같은 데이터 위치를 공유하는지 확인하세요. 테스트 중에도 같은 문제가 있는 상태를 읽을 수 있습니다.

클라이언트를 교체해야 한다면 다운로드 페이지에서 현재 플랫폼을 지원하는 Clash Plus를 우선 선택하거나 필요에 따라 Clash Verge Rev, FlClash 등을 고려하세요. Clash for Windows와 ClashX Meta는 유지 관리가 중단됐으므로 새 시스템 문제의 일반적인 해결책으로 권장하지 않습니다. 복구 후에는 먼저 일반 프록시를 테스트하고, 다음으로 TUN과 자동 업데이트를 켠 뒤 마지막으로 시작 시 자동 실행을 설정하세요. 이렇게 하면 프로그램 시작, 네트워크 트래픽 처리, 백그라운드 권한의 세 경로를 구분해 재발 시 점검을 쉽게 할 수 있습니다.

모바일 문제: VPN·백그라운드·네트워크 전환

모바일 프록시는 대개 시스템 VPN 기능을 사용하며 배터리 정책, 백그라운드 제한, Wi-Fi와 모바일 데이터 전환에도 영향을 받습니다. ‘시스템 VPN이 끊김’과 ‘VPN은 연결됐지만 요청 실패’를 먼저 구분하세요. 전자라면 권한과 프로세스 실행 상태를 우선 확인하고, 후자라면 출구, DNS, 네트워크 변경을 확인합니다. Android와 iOS는 권한 방식이 다르므로 데스크톱의 시스템 프록시 스위치 안내를 그대로 적용하지 마세요. 상태 표시줄 아이콘만 보고 모든 요청이 정상적으로 전달된다고 판단해서도 안 됩니다.

Android: VPN 권한과 앱별 설정 확인

처음 연결할 때 시스템의 VPN 권한 요청을 확인한 다음 시스템 VPN 설정에서 어떤 앱이 연결을 처리하는지 살펴보세요. 광고 차단 앱, 방화벽, 다른 VPN 도구가 같은 기능을 사용하려고 충돌할 수 있으므로 문제를 확인하는 동안 다른 도구를 종료하세요. ‘항상 켜진 VPN’ 또는 ‘VPN 없이 연결 차단’이 설정돼 있으면 클라이언트가 중지될 때 모든 네트워크 연결이 차단될 수 있습니다. 임시로 끄기 전에 해당 설정의 동작을 이해하고 Wi-Fi 문제로 잘못 판단하지 마세요.

일부 앱만 프록시를 우회한다면 클라이언트의 앱별 프록시 목록을 확인하세요. 화면에 따라 ‘선택한 앱만 프록시’와 ‘선택한 앱 제외’처럼 서로 반대되는 방식으로 동작할 수 있어 같은 앱을 선택해도 결과가 다릅니다. 변경 후 VPN 연결을 다시 설정하고 대상 앱을 완전히 종료했다가 다시 여는 경우가 많습니다. 업무 프로필, 앱 복제 기능, 시스템 구성 요소는 별도 ID를 사용할 수 있으므로 홈 화면의 앱 이름만 확인하지 말고 실제 앱 인스턴스를 살펴보세요.

화면을 끈 뒤 연결이 끊긴다면 시스템의 ‘배터리’와 ‘앱 관리’에서 클라이언트가 필요한 만큼 백그라운드에서 실행되도록 허용하고 백그라운드 데이터 제한도 확인하세요. 일부 기기는 자동 실행 관리 기능도 제공하므로 실제 사용에 필요한 권한을 부여해야 합니다. 설정을 바꾼 뒤 잠시 화면을 잠그고 같은 대상을 테스트해 프로세스가 재시작됐다는 로그가 있는지 확인하세요. 최근 앱 화면에서 앱을 고정하는 것만으로 배터리 제한이 해제되지는 않을 수 있습니다. 앱 하나를 고치려고 기기 전체의 절전 기능을 끄지도 마세요.

iOS: 설정·권한·재연결 확인

iOS에서는 Clash Plus를 우선 사용해 볼 수 있습니다. 설치 경로는 iOS 다운로드를 참고하고 공식 웹사이트는 clashplus.io입니다. 클라이언트에서 구독이 활성화됐는지 확인한 뒤 시스템 안내에 따라 VPN 구성을 추가하고 권한을 허용하세요. 연결이 즉시 끊기면 클라이언트 오류 기록과 시스템 VPN 목록을 확인해 이전 설정이 남아 있거나 다른 앱이 반복해서 연결을 시도하는지 살펴봅니다. 모든 네트워크 설정을 바로 삭제하지 말고 충돌 항목을 비활성화한 뒤 하나씩 확인하세요.

일부 앱은 네트워크 변경 전의 장시간 연결을 유지할 수 있습니다. 출구나 네트워크를 바꾼 뒤 VPN을 끊었다가 다시 연결하고 영향을 받은 앱을 완전히 종료한 후 다시 여세요. 시스템에 VPN 연결됨으로 표시돼도 터널이 설정됐다는 뜻일 뿐, 구독의 모든 출구에 접근할 수 있다는 의미는 아닙니다. 한 웹사이트만 실패하고 다른 사이트는 정상이라면 규칙과 DNS를 다시 확인하세요. 모든 요청이 실패하면 같은 네트워크의 다른 기기와 비교해 현재 네트워크의 제한 여부를 확인합니다.

네트워크 전환과 핫스팟 공유는 따로 테스트

Wi-Fi에서는 정상인데 모바일 데이터에서 실패하면 시스템에서 클라이언트의 모바일 데이터 사용을 허용했는지, 계정에 사용 가능한 데이터가 있는지, 앱이 저데이터 모드의 제한을 받는지 확인하세요. 같은 출구를 선택해 테스트하고 네트워크에 따른 UDP 또는 IPv6 동작 차이도 살펴봅니다. Wi-Fi와 모바일 데이터를 전환하면 로컬 IP 주소와 경로가 바뀌므로 기존 연결이 끊기는 일은 흔합니다. 다시 연결하면 복구되는 경우에는 전체 네트워크 설정을 바로 초기화하기보다 클라이언트의 백그라운드 상태 문제인지 계속 확인하세요.

증상	먼저 확인	검증 방법
화면을 끄면 연결 끊김	백그라운드 실행 및 배터리 제한	잠금 전후 프로세스와 연결 로그 비교
모바일 데이터에서만 실패	데이터 권한, 네트워크 프로토콜 차이	출구를 고정하고 Wi-Fi와 모바일 데이터 비교
일부 앱이 직접 연결	앱별 프록시 설정, 이전 연결	VPN을 다시 설정하고 대상 앱 재시작
핫스팟 기기가 프록시를 사용하지 않음	시스템의 공유 트래픽 경로	핫스팟 기기에서 프록시 연결을 별도로 테스트

휴대폰 자체에서 인터넷이 된다고 해서 핫스팟에 연결된 다른 기기의 트래픽도 휴대폰 VPN을 통과하는 것은 아닙니다. 공유 트래픽을 처리하는 방식은 시스템과 클라이언트 구현에 따라 다르므로 별도로 테스트해야 합니다. ‘LAN 연결 허용’은 다른 기기가 프록시 수신 포트에 연결할 수 있도록 할 뿐, 해당 기기의 프록시 설정까지 자동으로 변경하지는 않습니다. 꼭 사용해야 한다면 신뢰할 수 있는 네트워크에서만 열고 공용 네트워크에 수신 포트를 노출하지 마세요. 연결할 기기에는 휴대폰의 로컬 네트워크 주소와 올바른 포트를 입력해야 합니다.

모바일 문제 해결 후에는 앱을 사용 중일 때, 화면 잠금 후 복구될 때, 네트워크 전환 후의 세 상태를 각각 확인하세요. 필요한 백그라운드 권한은 유지하고 임시로 연 LAN 수신 포트는 닫은 뒤 평소 모드로 되돌리세요. 문제가 계속되면 기기 운영체제, 클라이언트 이름, 장애가 발생한 네트워크 유형, 오류 시간, 완료한 비교 테스트를 정리하세요. 원본 구독을 첨부하지 않아도 이 정보만으로 문제를 파악하는 데 도움이 됩니다. 다시 설정하려면 빠른 시작 가이드를, 용어가 헷갈리면 용어 설명을 참고하세요.