먼저 원인을 구분하세요: 규칙은 노드와 DNS 문제를 대신 해결하지 않습니다

GitHub, npm, Docker Hub 접속이 느리거나 실패한다면 서비스 도메인만 프록시로 보내는 규칙부터 시험하세요. 규칙은 연결된 도메인이나 IP에 어떤 정책을 적용할지 정할 뿐, 선택한 노드의 속도를 높이거나 끊어진 DNS를 복구하지는 않습니다. 브라우저에서는 되지만 터미널에서만 실패하는지, 특정 저장소나 패키지에서만 지연되는지, 모든 서비스가 느린지 먼저 나눠 보세요.

GitHub의 웹 페이지와 API, Git 전송, 릴리스 파일은 서로 다른 호스트를 사용할 수 있습니다. npm도 기본 레지스트리 외에 패키지 메타데이터와 다운로드 파일을 다른 도메인에서 제공할 수 있고, Docker Hub는 인증과 이미지 레이어 전송에 별도 주소를 이용할 수 있습니다. 따라서 도메인 하나만 규칙에 추가했는데 일부 요청만 계속 실패하는 상황은 충분히 발생합니다.

  • 서비스 전체가 실패: 선택한 프록시 노드의 연결 상태와 만료 여부, 클라이언트 로그를 먼저 확인하세요. 다른 노드로 바꾸어 같은 요청을 비교하면 노드 문제인지 규칙 문제인지 구분하기 쉽습니다.
  • 터미널 도구만 직접 연결: 셸의 프록시 환경 변수, 애플리케이션별 프록시 옵션, TUN 라우팅 가운데 실제 트래픽 유입 경로를 확인하세요. 시스템 프록시만 켜도 모든 명령줄 프로그램이 이를 따르는 것은 아닙니다.
  • 일부 다운로드만 실패: 로그에서 실패한 호스트를 찾고, 필요한 도메인을 규칙 세트에 추가하세요. 규칙을 넓히기 전에 해당 호스트가 정상적인 서비스 연결에 필요한 주소인지 확인하는 편이 안전합니다.

규칙 적용 범위와 순서: 앞에서 일치한 규칙이 먼저 처리됩니다

Clash 계열 설정은 일반적으로 rules를 위에서 아래로 검사합니다. 연결이 먼저 일치한 규칙의 정책으로 전달되므로, 개발 서비스 규칙은 광범위한 국가 코드 규칙, 일반 직접 연결 규칙, 마지막 기본 규칙보다 앞에 배치해야 합니다. 규칙을 파일에 추가했더라도 더 위쪽의 포괄 규칙이 먼저 일치하면 새 정책이 적용되지 않을 수 있습니다.

DOMAIN은 지정한 호스트 하나를, DOMAIN-SUFFIX는 도메인과 그 하위 도메인을 대상으로 합니다. 예를 들어 DOMAIN-SUFFIX,github.com은 github.com과 그 하위 호스트에 적용됩니다. 다만 githubusercontent.com은 별도 도메인이므로 github.com 규칙만으로 포함되지 않습니다. DOMAIN-KEYWORD는 이름에 특정 문자열이 들어가는 넓은 범위를 잡아 원치 않는 호스트까지 일치시킬 수 있어, 명확한 도메인을 알고 있다면 우선순위를 낮게 두거나 사용을 피하세요.

  • 서비스별 규칙: GitHub, npm, Docker처럼 확인된 도메인만 별도의 정책 그룹에 연결합니다.
  • 나머지 규칙: 기존 지역별, 광고 차단, 직접 연결 규칙을 유지하되 서로 겹치는 범위를 확인합니다.
  • 기본 규칙: 보통 MATCH가 마지막에 위치하며, 앞에서 처리되지 않은 나머지 트래픽에 적용됩니다.

서비스 규칙을 전부 같은 정책으로 보낼 필요는 없습니다. 먼저 하나의 개발용 그룹으로 연결해 동작을 확인한 뒤, 필요하면 GitHub와 패키지 레지스트리의 정책을 분리하세요. 정책 그룹 이름은 규칙에서 참조하는 이름과 정확히 같아야 합니다. 기존 구독의 그룹이나 규칙을 수정할 때는 원본을 백업하고, 클라이언트가 구독을 다시 업데이트했을 때 수동 변경이 덮어써지는지도 확인하세요.

rule-providers 구성: 개발 서비스 규칙을 별도 파일로 관리

rule-providers는 규칙 목록을 메인 설정과 분리해 불러오는 기능입니다. 아래 예시는 mihomo 계열 코어에서 로컬 YAML 파일을 읽는 구성 방식입니다. 실제 클라이언트가 사용하는 코어가 rule-providers의 해당 필드를 지원하는지 먼저 확인하세요. 구형 코어나 다른 구현에서는 format 또는 provider 동작이 다를 수 있습니다.

메인 설정의 정책 그룹과 provider 선언, 규칙 참조를 한꺼번에 추가해야 합니다. 개발 프록시 그룹에 넣은 노드 이름은 예시이므로 기존 설정에 실제로 존재하는 노드 또는 그룹 이름으로 바꾸세요. 노드 이름을 모르는 경우 기존 정책 그룹을 참조하도록 조정할 수 있습니다.

proxy-groups:
  - name: 개발 프록시
    type: select
    proxies:
      - 실제 프록시 노드
      - DIRECT

rule-providers:
  github:
    type: file
    behavior: domain
    format: yaml
    path: ./ruleset/github.yaml
  npm:
    type: file
    behavior: domain
    format: yaml
    path: ./ruleset/npm.yaml
  docker:
    type: file
    behavior: domain
    format: yaml
    path: ./ruleset/docker.yaml

rules:
  - RULE-SET,github,개발 프록시
  - RULE-SET,npm,개발 프록시
  - RULE-SET,docker,개발 프록시
  # 이 위치에 기존의 나머지 규칙을 유지
  - MATCH,DIRECT

각 파일에는 해당 서비스에 필요한 도메인 규칙만 넣습니다. 다음은 구조를 보여 주는 예시이며, 사용하는 서비스와 기능에 맞춰 검토하고 보완해야 합니다.

# ./ruleset/github.yaml
payload:
  - '+.github.com'
  - '+.githubusercontent.com'
  - '+.githubassets.com'
# ./ruleset/npm.yaml
payload:
  - '+.npmjs.org'
  - '+.npmjs.com'
# ./ruleset/docker.yaml
payload:
  - '+.docker.io'
  - '+.docker.com'

위 목록은 대표 도메인만 포함합니다. 예를 들어 이미지 레이어의 CDN 호스트가 로그에 나타나면 그 호스트를 별도로 확인해야 할 수 있습니다. 반대로 모든 cloudflare 또는 amazonaws 하위 도메인을 통째로 프록시하는 식으로 범위를 넓히면 관련 없는 서비스까지 정책에 들어갈 수 있습니다. 필요한 호스트를 요청 로그에서 확인하고, 변경 이유와 날짜를 함께 기록하세요.

실행 순서: 백업부터 연결 로그 검증까지

한 번에 여러 항목을 바꾸면 무엇이 문제를 해결했는지 알기 어렵습니다. 우선 설정 사본을 보관하고, 기존 노드와 일반 웹사이트 연결이 정상인지 확인한 다음 서비스 하나씩 적용하세요. 규칙이 적용됐다는 사실과 원격 서버가 요청을 성공적으로 처리했다는 사실은 서로 다릅니다.

  1. 현재 상태를 기록합니다. 클라이언트와 코어 버전, 현재 선택한 정책 그룹, 실패한 명령과 발생 시각을 적어 둡니다. 구독 기반 설정이면 원본 프로필을 복사하거나 클라이언트의 설정 내보내기 기능으로 백업합니다.
  2. 실패한 호스트를 찾습니다. 연결 로그에서 요청 시각에 나타난 도메인, 선택 정책, 연결 결과를 확인합니다. 로그 수준을 올려야 한다면 진단 후 원래 값으로 되돌리세요. 로그 전체를 공개하지 말고 인증 정보가 포함되지 않았는지도 확인합니다.
  3. 로컬 규칙 세트를 추가합니다. 먼저 GitHub만 별도 파일에 넣고, provider 선언과 RULE-SET 참조를 추가합니다. 규칙을 일반적인 기본 규칙보다 위에 두고, 정책 그룹 이름이 실제 설정과 일치하는지 확인합니다.
  4. 설정을 검사하고 불러옵니다. 클라이언트의 구성 검증 또는 파싱 기능을 실행합니다. 오류가 나면 오류가 가리키는 줄과 들여쓰기, provider 이름, 파일 경로를 확인한 뒤 활성 설정을 전환합니다. 구독을 새로 고쳐 수동 변경이 사라지지 않았는지도 살펴보세요.
  5. 서비스 요청을 재현합니다. 같은 네트워크와 같은 노드에서 실패했던 Git 작업, 패키지 설치, 이미지 가져오기를 다시 실행합니다. 로그에서 대상 호스트가 예상한 그룹으로 전달되는지 확인한 뒤 성공 여부와 시간을 기록합니다.
  6. 한 항목씩 확장합니다. GitHub 동작을 확인한 다음 npm, Docker 순서로 추가합니다. 새 항목을 넣은 직후 실패하면 방금 추가한 파일이나 정책을 우선 되돌려 원인을 좁힙니다.

명령줄 도구가 Clash의 로컬 HTTP 또는 SOCKS 포트를 직접 사용할 수 있다면 그 옵션과 시스템 프록시 설정을 확인하세요. 포트 번호를 임의로 가정하지 말고 클라이언트의 포트 화면과 설정 파일을 기준으로 삼아야 합니다. 시스템 프록시와 TUN을 동시에 켠 상태에서 진단하면 트래픽이 어느 경로를 탔는지 혼동할 수 있으므로, 가능한 한 처음에는 유입 경로를 하나만 테스트하세요.

로그 분석과 규칙 세트 유지 관리

로그에서 먼저 볼 항목은 요청 도메인, 일치한 규칙 또는 provider, 선택된 정책, 연결 결과입니다. 예상한 도메인이 DIRECT로 나갔다면 규칙의 순서, 도메인 범위, 활성 설정을 확인하세요. 올바른 그룹으로 전달됐는데 연결이 시간 초과된다면 다른 노드로 비교해 노드·출구 문제를 분리합니다. 연결이 성공했지만 다운로드가 느린 경우에는 해당 호스트가 다른 CDN을 사용하는지, DNS 응답이 바뀌었는지 확인할 필요가 있습니다.

  • provider를 찾을 수 없음: 선언한 이름과 RULE-SET에서 쓴 이름, 파일 경로 및 파일 읽기 권한을 대조합니다.
  • 규칙이 적용되지 않음: 더 위에서 일치하는 규칙이 있는지, 현재 활성 프로필이 편집한 프로필인지, 도메인 세트 형식이 맞는지 확인합니다.
  • 일부 요청만 실패: 실패 로그에서 누락된 호스트를 찾습니다. GitHub의 콘텐츠 호스트나 Docker 이미지 전송 호스트처럼 기본 도메인과 다른 주소가 쓰일 수 있습니다.
  • 규칙 추가 뒤 다른 서비스가 느려짐: 지나치게 넓은 접미사나 키워드 규칙을 제거하고, 서비스별 파일에서 필요한 도메인만 남깁니다.

로컬 파일 방식은 변경 시점을 직접 통제하기 쉽지만 각 기기에서 파일을 배포하고 관리해야 합니다. 원격 HTTP 규칙 제공자를 사용한다면 신뢰할 수 있는 출처, 다운로드 실패 시 동작, 갱신 간격, 형식 지원 여부를 확인하세요. 원격 주소를 설정에 넣는 것만으로 안전하거나 최신인 규칙이 보장되지는 않습니다. 규칙이 갱신되기 전과 후의 차이를 확인할 수 있도록 파일 사본이나 변경 기록을 유지하는 것이 좋습니다.

규칙 세트마다 담당 서비스, 포함 이유, 확인한 날짜, 변경한 호스트를 짧게 기록하세요. 사용하지 않는 항목은 주기적으로 제거하고, 도메인이 바뀌었다는 이유만으로 검증되지 않은 광범위 규칙을 추가하지 마세요. 잘못된 규칙이 전체 연결을 방해하면 해당 provider 참조를 잠시 비활성화하거나 백업 설정으로 돌아갈 수 있도록 복구 방법도 함께 보관하세요.