Clash 구독 업데이트 오류 해결: 링크 만료·형식 호환성·자동 업데이트 간격

먼저 구분하기: 구독 다운로드 실패인가, 설정 불러오기 실패인가

Clash 구독 업데이트는 보통 세 단계를 거칩니다. 클라이언트가 구독 주소에 요청을 보내고, 응답 내용을 파싱한 뒤, 유효한 설정을 코어에 전달해 불러옵니다. ‘업데이트 실패’가 표시돼도 노드가 이미 만료된 것은 아닐 수 있습니다. 기존 설정은 메모리에 남아 계속 작동할 수 있습니다. 반대로 다운로드에 성공했다고 표시되더라도 새 설정을 현재 코어가 받아들인다는 보장은 없습니다.

먼저 클라이언트의 ‘로그(Logs)’ 페이지를 열고, ‘프로필(Profiles)’ 페이지에서 해당 구독을 한 번 업데이트하세요. 클라이언트에 따라 이 페이지의 이름이 ‘구독’일 수 있으니 실제 화면을 기준으로 확인합니다. 작업 시간, 오류 키워드, 구독의 최근 업데이트 시간을 기록하고, 설정 삭제·코어 전환·네트워크 초기화를 동시에 진행하지 마세요.

• 요청 단계에서 실패: timeout, no such host, 403, 429 등의 메시지가 나타나면 주소, 네트워크, 서버 응답부터 확인하세요.
• 파싱 단계에서 실패: yaml, unmarshal, invalid config 등의 키워드가 보이면 응답 형식과 설정 내용을 중점적으로 확인하세요.
• 불러오기 단계에서 실패: 다운로드가 끝난 뒤 지원하지 않는 프록시 유형이라는 메시지가 나오거나 설정 적용에 실패하면 코어 호환성을 확인하세요.

링크 만료와 접근 제한: HTTP 상태 코드로 원인 찾기

서비스 제공업체 웹페이지가 아닌 구독 주소를 다시 복사하세요

구독 제공업체의 계정 페이지에서 이용 기간, 트래픽 상태, ‘구독 링크 초기화’ 여부를 확인하세요. 링크를 초기화하면 기존 주소의 토큰이 즉시 만료될 수 있습니다. 복사할 때는 Clash 또는 mihomo용 구독 메뉴를 선택하세요. 로그인 페이지, 계정 홈, QR 코드 이미지 주소, 임시 로그인 상태가 포함된 다운로드 주소를 복사하지 않도록 주의합니다.

구독 주소에는 보통 쿼리 매개변수가 포함됩니다. ? 뒤의 내용을 임의로 삭제하거나 메신저에 붙은 마침표·따옴표·줄바꿈까지 함께 복사하지 마세요. 기존 링크가 만료된 것 같다면 기존 구독 항목은 남겨 두고 새 주소로 별도 항목을 만들어 테스트하세요. 새 항목이 정상적으로 불러와지는 것을 확인한 뒤 기존 항목을 정리하면 됩니다.

브라우저에서 열린다고 클라이언트 업데이트도 성공하는 것은 아닙니다

브라우저는 로그인 쿠키를 보내거나 사용자 확인 절차를 거칠 수 있고, 클라이언트와 다른 프록시 경로를 사용할 수도 있습니다. 클라이언트의 구독 요청에는 이런 브라우저 상태가 전달되지 않는 경우가 많습니다. 브라우저에서 주소가 정상적으로 표시된다는 것은 브라우저의 현재 요청이 성공했다는 뜻일 뿐, 클라이언트 로그의 결과를 대신하지는 않습니다.

제공업체가 특정 요청 헤더나 클라이언트 유형을 요구한다면 공식 문서에 안내된 구독 주소를 사용하세요. User-Agent를 무작위로 바꾸며 반복 시도하지 마세요. 서버가 반환하는 형식이 달라져 기존 접근 문제가 형식 오류로 바뀔 수 있습니다.

형식 호환성: 전체 설정, 노드 목록, 코어 지원 여부 구분하기

구독 파일의 형식이 하나로 정해져 있는 것은 아닙니다. 일반적인 전체 Clash YAML에는 proxies, proxy-groups, rules가 포함됩니다. 프록시 모음 파일에는 보통 proxies만 있으며, proxy-providers에서 참조해 사용합니다. 공유 링크 목록이나 인코딩된 텍스트를 반환하는 주소도 있으므로, 모든 클라이언트가 이를 전체 설정으로 바로 불러올 수 있다고 가정하면 안 됩니다.

오류 내용에 따라 하나씩 확인하기

1. 본문이 HTML로 시작함: <!DOCTYPE html>이나 로그인 안내가 보이면 YAML이 아니라 웹페이지를 받은 것입니다. 구독 메뉴와 접근 권한을 다시 확인하세요.
2. YAML 줄 번호가 표시됨: 해당 줄 주변의 들여쓰기, 콜론, 따옴표를 확인하세요. YAML 들여쓰기에는 공백을 사용하고 Tab은 쓰지 마세요. 서식 있는 편집기에서 전각 문장부호를 필드명에 붙여 넣지 않도록 주의합니다.
3. 프록시 그룹이 없거나 참조 대상이 없다는 메시지가 표시됨: 규칙에서 참조하는 그룹 이름과 그룹에 포함된 노드 이름이 실제로 있는지 확인하세요. 노드 목록만 다운로드해도 모든 분기 규칙이 자동으로 추가되는 것은 아닙니다.
4. 알 수 없는 프록시 유형이나 필드라는 메시지가 표시됨: 실제로 실행 중인 코어와 버전을 확인하세요. 클라이언트 화면의 버전과 코어 버전은 별도 정보이며, 보통 ‘정보’ 또는 ‘코어’ 설정에서 확인할 수 있습니다.

mihomo는 Clash 설정 생태계를 이어받아 확장했지만, 구버전 Clash 코어가 새로 추가된 모든 프로토콜과 옵션을 지원하는 것은 아닙니다. 구독이 mihomo용으로 명시돼 있다면 호환되는 클라이언트와 코어를 사용하세요. 업그레이드하기 전에 오류 메시지 전체를 보관하고 설정을 백업하세요. 오류를 없애려고 정체를 알 수 없는 프로토콜 필드를 삭제하지 마세요.

업데이트 요청이 현재 프록시에 막힘: 직결과 프록시를 각각 테스트

흔히 발생하는 순환 문제는 구독 업데이트가 현재 프록시를 거쳐야 하는데, 현재 노드가 이미 작동하지 않는 경우입니다. 새 노드 정보를 받으려면 구독을 다운로드해야 하므로 웹페이지와 구독 요청이 모두 시간 초과될 수 있습니다. 반대로 현재 네트워크에서는 구독 도메인에 직접 연결할 수 없지만 클라이언트 업데이트는 기본적으로 직결을 사용하는 경우도 있습니다.

먼저 요청을 누가 보내는지 확인하세요. 일반적인 원격 설정은 클라이언트 관리 프로그램이 다운로드하지만, proxy-providers의 원격 프록시 모음은 코어가 관리합니다. 클라이언트의 ‘프록시를 통해 업데이트’ 옵션이 코어의 프록시 모음 요청까지 제어한다고 볼 수는 없습니다. Rule, Global 또는 시스템 프록시 설정만 바꿔도 업데이트 요청의 경로가 바뀐다는 보장은 없습니다.

1. 해당 구독의 편집 메뉴나 클라이언트 설정에서 ‘프록시를 통해 업데이트’, ‘프록시 업데이트’ 같은 옵션을 찾아보세요. 일부 클라이언트에는 별도 스위치가 없으므로 업데이트 로그나 설명서를 확인해야 합니다.
2. 현재 업데이트가 프록시를 사용한다면 먼저 정상 작동이 확인된 노드를 선택한 뒤 한 번 업데이트하세요. 그래도 실패하면 직결로 한 번 테스트합니다.
3. 현재 업데이트가 직결이고 로그에 구독 도메인 연결 시간 초과가 표시된다면, 작동하는 프록시를 사용해 테스트하세요. 휴대폰 핫스팟으로 잠시 전환해 현재 네트워크의 제한 여부를 비교해 볼 수도 있습니다.
4. 테스트가 끝나면 필요한 설정을 복원하고 어느 경로에서 성공했는지 기록하세요. 네트워크 전환과 설정 변경을 한꺼번에 하지 말고 한 번에 한 항목만 바꾸세요.

포트, DNS, 인증서 오류를 같은 문제로 취급하지 마세요

connection refused 127.0.0.1:7890은 요청이 로컬 7890 포트에 연결하려 했지만 실패했다는 뜻입니다. 코어가 실행 중인지, 실제 mixed-port가 여전히 7890인지 확인하세요. 포트를 7897로 변경했다면 업데이트 프록시 설정도 함께 바꿔야 합니다. 이전 포트를 계속 가리키지 않도록 주의하세요.

no such host는 도메인 이름 확인 문제에 가깝습니다. x509 또는 인증서 유효 기간 오류가 발생하면 먼저 Windows의 날짜, 시간, 시간대를 확인한 뒤 네트워크의 HTTPS 검사나 서버 인증서 문제를 살펴보세요. 문제를 가리기 위해 인증서 검증을 끄는 것은 권장하지 않습니다. 연결 시간 초과가 발생해도 곧바로 DNS 문제라고 단정하지 말고, 로그를 통해 이름 확인·연결·TLS 핸드셰이크 중 어디에서 멈췄는지 확인하세요.

자동 업데이트 간격: 클라이언트 구독과 프록시 모음은 별도로 설정

전체 구독의 예약 업데이트는 클라이언트에서 관리합니다

‘프로필(Profiles)’ 또는 ‘구독’ 페이지에서 해당 항목의 마우스 오른쪽 버튼 메뉴나 더보기 메뉴를 열고 ‘편집’, ‘정보 수정’ 또는 업데이트 설정을 찾으세요. 자동 업데이트가 켜져 있는지, 간격의 단위가 무엇인지 확인합니다. 메뉴 이름은 클라이언트마다 다르므로 특정 클라이언트의 설정 경로를 모든 Clash 클라이언트에 공통으로 적용하지 마세요.

• 제공업체가 별도 기준을 안내하지 않는다면 12시간마다 업데이트하도록 설정해 경과를 확인해 보세요. 단위가 분이면 720, 시간이면 12를 입력합니다.
• 하루에 한 번 업데이트하려면 1440분 또는 24시간으로 설정하세요. 숫자만 보지 말고 단위도 확인해야 합니다.
• 0을 ‘즉시 업데이트’로 간주하지 마세요. 자동 업데이트 끄기, 기본값 사용 등 다른 의미일 수 있으므로 해당 클라이언트의 안내를 확인하세요.
• 클라이언트가 서버 권장 간격을 읽을 수 있다면 제공업체의 안내를 우선 따르세요. 모든 클라이언트가 이 권장값을 인식하거나 적용하는 것은 아닙니다.

데스크톱 클라이언트를 종료하면 보통 해당 프로세스의 예약 작업도 중단됩니다. Windows가 절전 모드인 동안에는 일반 실행 상태처럼 구독을 가져오지 못합니다. 코어 서비스만 백그라운드에서 실행 중이어도 전체 구독 업데이트를 담당하는 클라이언트 프로세스까지 계속 작동한다는 뜻은 아닙니다. 예약 업데이트가 필요하면 클라이언트를 실행 상태로 유지하고, 절전 해제나 재시작 후 업데이트 시간이 바뀌었는지 확인하세요.

proxy-providers의 interval 단위는 초입니다

mihomo의 원격 프록시 모음을 사용하는 경우 interval은 코어 설정에 해당하며 단위는 초입니다. 아래는 필드 간 관계를 설명하기 위한 일부 예시일 뿐, 완전한 구독 설정이 아닙니다. 예시 도메인은 실제 서비스를 제공하지 않으므로 사용할 때는 신뢰할 수 있는 본인 주소를 입력해야 합니다.

proxy-providers:
  remote-nodes:
    type: http
    url: "https://example.com/nodes.yaml"
    path: ./providers/remote-nodes.yaml
    interval: 86400

여기서 86400은 24시간, 43200은 12시간, 3600은 1시간을 뜻합니다. 프록시 모음은 프록시 그룹에서 use로 참조해야 하며, 응답 내용도 프록시 모음 형식이어야 합니다. 이 필드를 YAML 최상위에 바로 추가해 클라이언트의 전체 구독 새로고침을 제어하려고 해서는 안 됩니다.

프록시 모음의 health-check.interval은 노드 상태 확인 주기이며, 구독 다운로드 주기가 아닙니다. 상태 확인 간격을 300초로 바꿔도 해당 검사 작업에만 영향을 줍니다. 5분마다 노드 목록을 다시 가져온다는 뜻이 아닙니다. 장기적으로 설정을 변경할 때는 클라이언트가 지원하는 덮어쓰기나 병합 기능을 사용해 다음 구독 업데이트에서 로컬 변경 사항이 덮어쓰이지 않게 하세요.

수동 강제 새로고침: 기존 설정을 보존하고 새 내용 확인하기

링크가 복구됐는지 확인하거나 제공업체가 노드 변경을 공지했을 때 새 설정을 바로 받으려면 수동으로 업데이트할 수 있습니다. ‘강제 새로고침’은 공통 메뉴 이름이 아닙니다. 어떤 클라이언트에는 ‘업데이트’만 있고, 다른 클라이언트에는 ‘모두 업데이트’나 로컬 업데이트 주기를 무시하는 기능이 있습니다. 강제 새로고침으로 서버 캐시를 우회할 수 있는 것은 아니며 만료된 토큰도 복구되지 않습니다.

1. 현재 상태 저장: 현재 적용된 설정 이름, 업데이트 시간, 정상 작동하는 노드를 기록하세요. 필요한 경우 로컬의 보호된 폴더에 백업을 내보냅니다.
2. 해당 항목만 새로고침: 설정 목록에서 해당 구독을 한 번 ‘업데이트’하세요. 여러 구독이 동시에 실패해 원인을 찾기 어려워지는 일을 피할 수 있습니다.
3. 결과 확인: 로그의 시간을 비교해 요청이 완료됐는지 확인하세요. 최근 업데이트 시간이 바뀌었는지, 파싱이나 코어 불러오기 오류가 발생했는지도 살펴봅니다.
4. 적용 여부 확인: 클라이언트가 자동으로 다시 불러오지 않았다면 업데이트된 설정을 직접 선택해 적용하세요. 그런 다음 프록시 그룹이 있는지, 규칙 모드가 예상대로인지 확인합니다.
5. 실제 동작 테스트: 직결되어야 하는 웹사이트와 프록시를 거쳐야 하는 대상을 각각 테스트하고, 연결 기록에서 적용된 규칙과 출구를 확인하세요. 노드 수가 바뀌었는지만으로는 충분하지 않습니다.

업데이트 시간은 바뀌었지만 노드 목록이 그대로라면 상위 서버의 내용이 변경되지 않았을 수 있습니다. 반드시 캐시 문제라는 뜻은 아닙니다. 주소에 임의의 매개변수를 계속 추가하는 것도 일반적인 해결책이 아닙니다. 서명이 포함된 링크는 그렇게 하면 무효가 될 수 있습니다. 새 설정을 불러오지 못했다면 로그를 보관하고 정상 작동하는 설정으로 되돌리세요. 설정 폴더 전체를 반복해서 삭제하지 마세요.

계속 실패한다면 다음 정보를 정리하세요

구독 제공업체나 클라이언트 프로젝트에 문의하기 전에 최소한의 진단 기록을 준비하면 ‘업데이트가 안 돼요’라는 설명보다 문제를 파악하기 쉽습니다. 오류 메시지는 원문 그대로 보관하되 구독 주소, 인증 헤더, 노드 인증 정보는 공개하지 마세요.

• 실행 환경: Windows 버전, 클라이언트 이름과 전체 버전 번호, 실제 코어 이름과 버전 번호.
• 문제 발생 시간: 예를 들어 현지 시간 09:20에 수동 업데이트를 실행했다고 적고, 서버에서 로그를 확인할 수 있도록 시간대를 함께 표시하세요.
• 실패 단계: 요청 실패인지, YAML 파싱 실패인지, 다운로드는 성공했지만 적용에 실패한 것인지 구분하세요.
• 비교 결과: 직결은 성공했는지, 사용 가능한 프록시를 통한 요청은 성공했는지, 핫스팟으로 전환해도 실패했는지 기록하세요.
• 예약 업데이트 설정: 자동 업데이트가 켜져 있는지, 간격 숫자와 단위는 무엇인지, 문제 발생 당시 클라이언트가 종료됐거나 컴퓨터가 절전 상태였는지 적으세요.

항상 같은 순서로 확인하세요. 먼저 링크와 계정 상태를 확인하고, 다음으로 응답 형식을 점검합니다. 이어서 업데이트 요청의 네트워크 경로를 비교하고, 마지막으로 예약 작업을 확인하세요. 이렇게 하면 서버·클라이언트·코어 문제를 분리할 수 있으며, 일시적인 구독 문제 때문에 Windows 네트워크 설정 전체를 초기화하는 일도 피할 수 있습니다.