Docker 풀 느림·타임아웃? Clash 레지스트리 분기 가속 (2026)

왜 `docker pull`만 유난히 느리거나 타임아웃일까

컨테이너 이미지는 레이어 단위로 여러 번의 HTTP 요청을 이어 붙여 내려받습니다. 네트워크가 조금만 불안정해도 한 레이어에서 멈춘 뒤 전체가 실패하는 패턴이 흔하고, CI나 로컬 빌드 모두 같은 증상을 공유합니다. 사용자는 보통 “노드가 느려서”라고 생각하지만, 실제로는 어떤 호스트로 나가느냐와 프록시·DNS·직결 경로가 섞였는지가 더 큰 변수인 경우가 많습니다.

예를 들어 Docker Hub를 쓸 때는 registry-1.docker.io·인증·CDN에 해당하는 호스트가 함께 등장하고, GitHub Container Registry를 쓰면 ghcr.io가, Google 쪽 아티팩트는 gcr.io·*.pkg.dev 계열이 붙습니다. 이 도메인들이 서로 다른 규칙 줄에 걸리면 TLS·리다이렉트·토큰이 엇갈려 중간에만 끊기는 형태가 됩니다. 반대로 “모든 트래픽을 한 번에 노드로” 보내면, 사내 레지스트리나 지역 미러까지 불필요한 홉을 타 느려지거나, 보안 정책상 막히는 경우도 있습니다.

전역 프록시가 오히려 방해가 되는 경우

개발자 프록시를 켠 상태에서 Docker만 문제일 때, 먼저 의심할 것은 경로가 한 가지로 고정됐는지입니다. 시스템 전체를 TUN으로 흡수하거나 브라우저만이 아니라 모든 TCP가 같은 출구를 보면, 다음이 자주 발생합니다.

사내·VPC 레지스트리(예: registry.corp.local, 사설 IP 대역)까지 해외 노드를 거쳐 라우팅이 꼬이거나 지연된다.
국내/교육망 미러를 쓰려는데, 넓은 MATCH 규칙이 먼저 적용되어 직결이 아닌 프록시로 나간다.
CI 러너는 빠른데 로컬만 느리다면, HTTP 프록시 환경 변수와 Clash 경로가 이중으로 걸려 충돌한다.

그래서 목표는 “빠른 노드 하나 찾기”보다 레지스트리·미러·내부망을 규칙으로 분리해, 공용 레지스트리만 개발자 프록시(또는 전용 그룹)로 보내고 나머지는 DIRECT로 두는 쪽에 가깝습니다. 웹 AI 사이트만 나누는 절차는 AI 사이트 분기 가이드에 두고, 여기서는 컨테이너 레지스트리 도메인에 초점을 맞춥니다.

나눠서 생각할 레지스트리 도메인 묶음

실제 프로필에는 팀에서 쓰는 이미지 경로에 맞춰 조정해야 합니다. 다만 설계할 때 자주 등장하는 묶음은 아래와 같습니다.

Docker Hub: docker.io, registry-1.docker.io, auth.docker.io, (환경에 따라) 관련 CDN 호스트.
GitHub Container Registry: ghcr.io.
Google: gcr.io, *.gcr.io, Artifact Registry 사용 시 pkg.dev 계열.
Quay·기타: quay.io, mcr.microsoft.com, public.ecr.aws 등.

커뮤니티 RULE-SET이나 구독에 “컨테이너/클라우드” 카테고리가 있다면 그 이름을 그대로 쓰되, 규칙 순서에서 사내 주소·미러 예외가 위에 오는지 반드시 확인합니다. RULE-SET 전체 그림과 Fake-IP는 YAML 심층 가이드와 함께 보는 것이 안전합니다.

팁

한 번에 모든 퍼블릭 레지스트리를 나열하기보다, 팀이 실제로 docker pull하는 이미지 출처부터 좁혀 최소 세트를 만든 뒤, 실패 로그에 나온 호스트를 추가하는 방식이 유지보수에 유리합니다.

`proxy-groups`와 `rules`로 레지스트리 전용 출구 만들기

실무에서는 PROXY_REGISTRY 같은 이름 고정 그룹을 두고, 멤버는 범용 자동 선택 그룹과 분리합니다. 이유는 레지스트리는 대용량·장시간 연결이 많아, 일반 웹 측정 URL에 맞춘 url-test가 항상 최적인 것은 아니기 때문입니다. 필요하면 지연보다 안정적인 고정 노드를 select로 두는 편이 낫습니다.

rules에서는 (1) 사내·사설 IP·내부 도메인 DIRECT, (2) 팀이 쓰는 국내 미러 호스트 DIRECT, (3) 공용 레지스트리 RULE-SET 또는 DOMAIN-SUFFIX를 PROXY_REGISTRY, (4) 그 아래 일반 규칙 순으로 쌓는 패턴이 많습니다. 핵심은 좁은 예외가 넓은 MATCH보다 위에 있다는 점입니다.

# Conceptual excerpt — adapt names and rule-sets to your profile
proxy-groups:
  - name: PROXY_REGISTRY
    type: select
    proxies:
      - NODE_DEV_1
      - NODE_DEV_2
      - PROXY_DEFAULT

rules:
  - IP-CIDR,10.0.0.0/8,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT
  - DOMAIN-SUFFIX,corp-registry.local,DIRECT
  - DOMAIN-SUFFIX,mirror.example.edu,DIRECT
  - RULE-SET,container_registries,PROXY_REGISTRY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY_DEFAULT

위는 개념 예시이며, 실제 키 이름·RULE-SET 경로는 사용 중인 프로필에 맞게 바꿔야 합니다. 구독에서 노드 묶음을 나누는 방법은 구독 변환·필터링 가이드를 참고하면 레지스트리 전용 그룹에 넣을 서버만 골라 담기 쉽습니다.

Docker·containerd 쪽: 코어만 Clash와 맞추기

Clash 규칙이 아무리 정교해도, Docker 데몬이 시스템 프록시를 타지 않거나 반대로 환경 변수 HTTP_PROXY만 보면 경로가 갈라집니다. 대표적인 정리는 다음과 같습니다.

Docker Desktop(Windows/macOS): 앱 설정의 프록시 항목이 dockerd에 어떻게 전달되는지 확인합니다. Clash를 TUN으로 쓰면 애플리케이션별 설정을 덜 건드려도 되는 경우가 많지만, 다른 VPN과 동시 사용이면 라우팅이 겹칠 수 있습니다.
Linux 서비스: /etc/docker/daemon.json의 레지스트리 미러·인증서, systemd 유닛에 붙은 HTTP_PROXY 등이 Clash와 이중 적용되지 않았는지 봅니다.
nerdctl·containerd: 상위 오케스트레이션과 같은 노드에서 돌 때, 호스트 Clash와 같은 DNS 뷰를 쓰는지 확인합니다.

“규칙은 맞는데 pull만 이상하다”면, 먼저 클라이언트가 어떤 경로로 TCP를 여는지를 좁히고, 그다음 노드 풀을 의심하는 순서가 시간을 아낍니다.

DNS·TUN: 레지스트리 분기와 맞물리는 지점

Fake-IP를 쓰면 로컬 앱이 보는 IP와 터널 내부 질의가 달라질 수 있어, 레지스트리처럼 여러 호스트를 연쇄로 부르는 작업에서 증상이 드러나기 쉽습니다. fake-ip-filter에 레지스트리 관련 도메인을 넣어야 하는지, 아니면 TUN으로 해석 경로를 통일할지는 환경마다 다릅니다.

중요한 원칙은 하나입니다. 브라우저 확장 프록시만 켜 두고 터미널의 docker는 시스템 경로를 쓰면, “웹은 되는데 pull만 안 된다”가 자주 납니다. 개발자 프록시를 쓸 때는 한 가지 모드로 통일하는 것이 좋습니다. DNS·Fake-IP 전체는 YAML 가이드의 DNS·Fake-IP 절과 함께 보세요.

(선택) 프로세스·스크립트만 다른 출구

mihomo 계열에서 프로세스 기반 규칙을 지원하는 클라이언트라면, CI용 러너나 특정 빌드 스크립트만 PROXY_REGISTRY로 보내고 일상 브라우징은 기본 그룹에 두는 식의 세밀한 분리가 가능합니다. 다만 플랫폼·권한·성능 특성이 있으므로, 도메인 분기로 먼저 안정화한 뒤 필요할 때 확장하는 순서를 권합니다.

주의

회사 보안 정책·클라우드 제공자 약관·레지스트리 이용 약관을 위반하는 경로 우회는 다루지 않습니다. 이 글은 합법적으로 접근 가능한 레지스트리에서 기술적 경로 불일치로 인한 느림·끊김을 줄이는 설정에 한합니다.

점검 순서 체크리스트

Clash 모드가 rule이고, 편집 중인 프로필이 실제로 로드됐는지 확인한다.
rules에서 사내·미러·직결 예외가 공용 레지스트리 RULE-SET보다 위에 있는지 본다.
PROXY_REGISTRY가 가리키는 노드가 의도한 출구인지, 자동 전환이 과하지 않은지 본다.
Docker·containerd에 별도 HTTP_PROXY가 남아 이중으로 걸리지 않았는지 본다.
Fake-IP·TUN·시스템 프록시 중 무엇을 쓰는지 통일하고, 다른 VPN과의 중복을 제거한다.
실패 시 레이어 다운로드 로그에 나온 호스트 이름을 규칙에 반영한다.

정리

클라우드 네이티브와 로컬 개발에서 docker pull은 AI 도구·CI·실험 환경까지 연결되는 기반 트래픽입니다. 전역 프록시 한 방으로는 빠르게 보이지만, 사내 레지스트리·미러·내부망까지 끌고 가면 오히려 불안정해질 수 있습니다. Clash·mihomo는 도메인·IP·(지원 시) 프로세스 단위로 경로를 명시해 두면, “어디서 끊기는지”를 빠르게 좁힐 수 있습니다.

최신 클라이언트와 코어 조합은 다운로드 페이지에서 확인할 수 있습니다. → Clash를 무료로 내려받아 프로필을 정리한 뒤, 레지스트리 전용 전략 그룹과 예외 규칙부터 순서대로 맞춰 보시기 바랍니다.