1. 새 LTS 시즌에 반쪽 통신이 생기는 이유

Ubuntu 26.04 프록시 환경에서 sudo apt update는 성공하는데 특정 저장소만 실패하거나, 반대로 deb 패키지는 받아오는데 snap refresh만 멈춘다면 단일 원인이라기보다 호스트 이름별 출구 불일치가 겹친 경우가 많습니다. 공항 구독 규칙에 GEOIP나 대륙 직결 같은 넓은 규칙이 있으면, 같은 조직이라도 CDN 엣지만 다른 노드로 나가거나 한쪽만 차단되는 현상이 재현됩니다. 업그레이드 직후에는 DNS 캐시·프록시 테이블·이전 세션이 섞여 증상이 들쭉날쭉해 보일 수 있어, 한 번 재현되는 표본을 로그로 고정하는 습관이 중요합니다.

2. apt가 만지는 Canonical·미러 호스트 묶음

기본 설정에서는 archive.ubuntu.com 또는 선택한 지역 미러가 패키지 목록과 바이너리를 제공하고, 보안 업데이트 전용에는 security.ubuntu.com 계열이 따로 붙습니다. 추가 저장소나 포트 아카이브(ports.ubuntu.com), 클라우드 메타데이터와 연관된 호스트까지 합치면 규칙 한 줄로 묶기 어렵습니다. “미러 주소만 바꿨는데 왜 그대로인가”에 대한 첫 답은 실제 접속에 사용된 FQDN이 sources.list와 동일한지입니다. 리다이렉트·IPv6 우선·프록시 PAC 미적용 등으로 로그에 찍히는 이름이 사용자가 편집한 줄과 다를 수 있습니다.

3. Snap 스토어와 CDN은 또 다른 동작입니다

Snap 스토어 프록시 문제로 오해되기 쉬운 지점은 snap 데몬이 단일 호스트만 두드리지 않는다는 것입니다. 스냅 패키지 서명 검증·메타데이터·실제 페이로드가 서로 다른 서브도메인과 CDN 접미사를 거칠 수 있어, 일부만 안정 노드를 타면 진행 표시줄이 길게 멈춘 채 타임아웃으로 끝납니다. 특히 장시간 연결이 필요한 동안 다른 규칙이 개입하면 재시도 루프가 길어집니다. 브라우저로 스토어 페이지를 여는 것과 snap CLI가 사용하는 호스트 묶음은 완전히 같지 않으므로, “웹만 되고 스냅만 안 된다”면 스냅 전용 행을 로그에서 따로 모아야 합니다.

4. 국내 미러만으로 안 풀리는 전형

동아시아 공개 미러로 바꿔 지연은 줄었는데 여전히 간헐적으로 실패한다면 병목이 해외 물리 거리만은 아닙니다. 미러 앞단에서 TLS 핸드셰이크까지 도달했는데 프록시 코어에서 다른 정책 그룹으로 분류되는 행이 남았는지 확인해야 합니다. 반대로 미러 자체는 빠른데 회사 방화벽·출구 장비가 특정 Canonical 접미사만 검사한다면 같은 증상이 납니다. 이때 필요한 것은 목록 더 추가보다 실패한 연결 행을 규칙 상단으로 올려 재현 여부를 줄이는 일입니다.

5. 권장 점검 순서: DNS → 모드 → 규칙 → 재현 명령

  1. DNS: fake-ip와 도메인 규칙 진입 순서를 확인합니다. 이름이 규칙 엔진에 들어올 때와 실제 백엔드와 어긋나면 HTTPS 재시도가 반복됩니다.
  2. 모드: 시스템 프록시만인지 TUN까지 사용하는지 기록합니다. apt와 snap 데몬은 환경 변수 http_proxy를 따르지 않는 경우가 있어 경로가 브라우저와 다릅니다.
  3. 규칙: 연결 패널에서 ubuntu·canonical·snapcraft 문자열로 필터링해 어떤 정책 이름이 매칭되는지 봅니다.
  4. 재현: apt update 한 번과 snap download 또는 작은 스냅 설치 한 번을 각각 실행해 시간순 행을 비교합니다.
  5. 충돌: 하단의 넓은 GEOIP·MATCH 규칙이 Canonical 블록보다 먼저 소모되는지 확인합니다.

6. 검증 명령과 관측 포인트

문제를 다른 레이어와 분리하려면 동일 호스트에 대해 프록시를 명시했을 때와 생략했을 때를 나란히 비교합니다. 예를 들어 curl로 특정 저장소 메타데이터 URL을 받아 오는 테스트를 할 때도 마찬가지입니다. 타임아웃 메시지가 “연결 시간 초과”인지 “TLS 실패”인지에 따라 추적 포인트가 달라집니다. 배포판 업그레이드 직후에는 이전 릴리스에서 남은 프록시 관련 유닛 환경 변수나 컨테이너 재시작 순서까지 함께 점검하는 편이 안전합니다.

7. 규칙 예시 (정책 그룹 이름은 교체)

# Example only — replace UBUNTU_CANONICAL_GROUP with your policy group; verify FQDNs in live logs
rules:
  - DOMAIN-SUFFIX,ubuntu.com,UBUNTU_CANONICAL_GROUP
  - DOMAIN-SUFFIX,ubuntu.net,UBUNTU_CANONICAL_GROUP
  - DOMAIN-SUFFIX,canonical.com,UBUNTU_CANONICAL_GROUP
  - DOMAIN-SUFFIX,snapcraft.io,UBUNTU_CANONICAL_GROUP
  - DOMAIN-KEYWORD,snapcdn,UBUNTU_CANONICAL_GROUP

DOMAIN-KEYWORD는 범위가 넓어지므로 로그에서 실제 접미사가 확인된 뒤에만 추가하고, 필요하면 더 좁은 DOMAIN-SUFFIX로 바꿉니다. 미러 호스트가 학교·클라우드 제공자 접두사라면 해당 접미사만 따로 블록으로 두어 다른 트래픽과 섞이지 않게 합니다.

8. systemd 상시 실행과 TUN을 동시에 볼 때

Mihomo를 systemd 유닛으로 올린 구성이라면 재시작 타이밍에 따라 순간적으로 라우팅 테이블과 iptables nft 규칙이 어긋날 수 있습니다. 업그레이드 후 재부팅 직후 첫 apt Clash 테스트만 실패하고 두 번째부터 성공한다면 부팅 순서 문제일 가능성을 의심합니다. Linux Mihomo 글에서 유닛 의존성과 재시작 정책을 정리한 뒤 이 글의 호스트별 규칙을 적용하면 재발을 줄일 수 있습니다.

9. GEOIP·MATCH와의 충돌 줄이기

구독 규칙에 특정 국가 코드를 직결로 보내는 줄이 많으면 글로벌 CDN 호스트만 의도치 않게 빠져 나갑니다. Canonical 관련 블록을 로컬 파일 상단에 두거나, 공급자 규칙 뒤에서 덮어쓰기 순서가 유지되는지 주기적으로 확인하세요. 구독이 갱신될 때마다 순서가 바뀌는 경우라면 로컬 규칙 파일을 분리해 버전 관리하는 편이 운영에 유리합니다.

10. Mihomo 설치 글과 역할 분담

Linux Mihomo 설치 글은 바이너리 배치와 코어 구동 자체를 다룹니다. 이 글은 그 위에서 패키지 매니저와 스토어가 요구하는 호스트 단위 출구 일관성에 초점을 맞춥니다. 두 글을 순서대로 읽으면 “설치는 됐는데 업데이트만 불안정하다”는 단계에서 바로 규칙 검증으로 넘어갈 수 있습니다. 프로필 편집 흐름이 필요하면 구독 가져오기 튜토리얼에서 로컬 규칙 합치기 순서를 먼저 정리하는 편이 좋습니다.

11. 다른 반쪽 통신 글과 비교할 때

Windows 협업 앱 글들은 REST·CDN·실시간 소켓 축을 나누지만, 서버형 리눅스에서는 패키지 매니저와 스토어 데몬이 사용자 세션보다 데몬 권한과 전역 라우팅에 더 의존합니다. 증상 언어는 비슷해도 확인해야 할 프로세스 이름과 환경 변수가 다릅니다. 공통으로 막히면 일반 트러블슈팅 가이드에서 포트·프로필 유효성을 먼저 확인한 뒤 돌아오세요.

12. 준수 안내

이 글은 불법 우회나 타 네트워크 무단 이용을 조장하지 않으며, 소속 조직이 허용한 범위에서 출구 일관성을 맞추는 운영 목적을 전제로 합니다. 조직 보안 정책이 업데이트 트래픽을 특정 경로로만 허용한다면 그 제약을 우선해야 합니다.

13. 정리: 미러 주소보다 출구 로그가 우선입니다

Ubuntu 26.04 업그레이드 직후 apt와 Snap 스토어가 동시에 불안정하면, Canonical 계열 호스트가 한 프록시 정책으로 묶였는지 연결 로그로 먼저 증명하는 편이 빠릅니다. 규칙을 고친 뒤에는 동일 명령으로 재현 테스트를 반복하고, systemd·TUN·부팅 순서까지 포함해 재발 조건을 좁히세요.

데스크톱에서도 규칙 편집과 로그 확인을 한 화면에서 처리할 수 있는 Mihomo 기반 클라이언트를 쓰면 반쪽 통신 원인을 줄이는 데 도움이 됩니다. 다른 범용 도구와 비교해도 구독과 분류 로그가 함께 있으면 “일부 호스트만 빠진다”는 증상을 빠르게 좁힐 수 있습니다. → Clash를 무료로 내려받아 Ubuntu 업데이트 경로를 한 출구에 맞춰 보세요