Ubuntu 24.04에서 APT 업데이트 중 Temporary failure resolving 오류를 해결하는 방법

적용 환경

이 문서에서 알아볼 내용

• APT 오류가 DNS 문제인지 인터넷 연결 문제인지 구분하는 방법
• systemd-resolved 상태와 현재 DNS 서버 확인 방법
• /etc/resolv.conf 연결 상태 확인 및 기본 구성 복구 방법
• Netplan에서 DNS 서버를 지정하거나 DHCP DNS를 교체하는 방법
• 복구 후 apt update와 이름 해석을 검증하는 방법

가장 먼저 네트워크와 DNS를 구분해 확인

Temporary failure resolving은 호스트 이름을 IP 주소로 변환하지 못했다는 의미입니다. 그러나 DNS 서버까지 도달할 네트워크 경로 자체가 없는 경우에도 같은 형태로 이름 해석이 실패할 수 있으므로, 저장소 파일을 수정하기 전에 네트워크 연결부터 확인하는 것이 중요합니다.

1. 실제 APT 오류 다시 확인

sudo apt update

오류에 표시되는 호스트 이름을 확인합니다. Ubuntu 기본 저장소라면 archive.ubuntu.com, security.ubuntu.com 또는 아키텍처와 환경에 따라 다른 미러 주소가 표시될 수 있습니다.

2. 인터페이스와 기본 경로 확인

ip -br address
ip route

외부 통신에 사용하는 인터페이스에 IPv4 또는 IPv6 주소가 존재하는지 확인하고, IPv4 환경이라면 일반적으로 default via ... 형태의 기본 경로가 있어야 합니다. 기본 경로가 없다면 DNS보다 먼저 Netplan 또는 상위 네트워크 설정을 복구해야 합니다.

3. IP 주소로 외부 통신 확인

ping -c 3 1.1.1.1
ip route get 1.1.1.1

IP 주소로도 통신되지 않는다면 DNS만의 문제가 아닐 가능성이 높습니다. 서버 IP, 서브넷, 기본 게이트웨이, VLAN, 클라우드 보안 정책 또는 상위 라우팅을 먼저 확인하십시오. 일부 네트워크는 ICMP를 차단할 수 있으므로 ping 실패만으로 인터넷 단절을 단정하지 말고 ip route 결과도 함께 확인합니다.

4. DNS 이름 해석 확인

getent hosts archive.ubuntu.com
resolvectl query archive.ubuntu.com

IP 통신은 가능하지만 위 명령에서 주소가 반환되지 않는다면 DNS 설정을 중심으로 점검합니다. getent는 실제 시스템 이름 해석 경로를 확인하는 데 유용하며, resolvectl query는 systemd-resolved를 통한 조회 상태를 확인할 수 있습니다.

systemd-resolved 상태 확인 및 복구

Ubuntu 24.04의 일반적인 구성에서는 systemd-resolved가 로컬 DNS 이름 해석을 담당합니다. 먼저 서비스와 인터페이스별 DNS 서버가 정상적으로 인식되는지 확인합니다.

systemctl is-active systemd-resolved
systemctl status systemd-resolved --no-pager
resolvectl status

systemctl is-active 결과가 active인지 확인하고, resolvectl status에서 실제 네트워크 인터페이스에 DNS 서버 주소가 표시되는지 확인합니다.

서비스가 일시적으로 비정상 상태라면 재시작한 뒤 다시 조회합니다.

sudo systemctl restart systemd-resolved
sudo resolvectl flush-caches
resolvectl status
getent hosts archive.ubuntu.com

기본 Ubuntu 구성에서 서비스가 비활성화되어 있고 별도의 DNS 관리 프로그램을 사용하지 않는 것이 확인된 경우에는 다음과 같이 활성화할 수 있습니다.

sudo systemctl enable --now systemd-resolved

서비스 오류 원인은 현재 부팅의 저널에서 확인합니다.

sudo journalctl -u systemd-resolved -b --no-pager

/etc/resolv.conf 확인

/etc/resolv.conf가 잘못된 파일을 가리키거나 빈 파일로 바뀌면 프로그램이 DNS 서버를 찾지 못할 수 있습니다. 현재 파일의 형태와 내용을 확인합니다.

ls -l /etc/resolv.conf
cat /etc/resolv.conf

Ubuntu의 일반적인 systemd-resolved 구성에서는 /etc/resolv.conf가 /run/systemd/resolve/stub-resolv.conf 또는 /run/systemd/resolve/resolv.conf와 연결될 수 있습니다. 로컬 스텁 리졸버 방식을 사용하는 경우에는 127.0.0.53이 nameserver로 표시될 수 있습니다.

기본 스텁 리졸버 구성을 사용해야 하는 서버인데 심볼릭 링크가 삭제되었거나 잘못된 경로로 변경된 것이 확인되었다면 다음과 같이 복구할 수 있습니다.

sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
sudo systemctl restart systemd-resolved
getent hosts archive.ubuntu.com

Netplan DNS 설정 확인 및 수정

재부팅 후에도 DNS 오류가 반복되거나 DHCP에서 잘못된 DNS 서버를 전달받는다면 Netplan 설정을 확인합니다. 먼저 현재 인터페이스 이름과 병합된 Netplan 구성을 확인하십시오.

ip -br link
ls -l /etc/netplan/
sudo netplan get
sudo netplan status --all

설정을 수정하기 전에 기존 Netplan 파일을 백업합니다.

sudo cp -a /etc/netplan /root/netplan-backup

DHCP는 유지하고 DNS 서버만 지정하는 예시

아래 예시는 인터페이스 이름이 ens3인 경우입니다. 실제 서버의 인터페이스 이름으로 변경하고, DNS 주소는 호스팅 사업자나 조직에서 제공하는 DNS를 우선 사용하십시오.

network:
  version: 2
  renderer: networkd
  ethernets:
    ens3:
      dhcp4: true
      dhcp4-overrides:
        use-dns: false
      nameservers:
        addresses:
          - 1.1.1.1
          - 8.8.8.8

이미 고정 IP를 사용하는 서버라면 기존 addresses와 routes는 그대로 유지하고 nameservers 항목만 올바르게 수정하십시오. 원격 서버에서 네트워크 설정을 잘못 변경하면 SSH 연결이 끊길 수 있으므로 전체 파일을 예시로 덮어쓰는 방식은 권장하지 않습니다.

YAML 문법을 먼저 검사합니다.

sudo netplan generate

오류가 없다면 원격 서버에서는 자동 롤백 기능이 있는 netplan try를 우선 사용합니다.

sudo netplan try

Netplan 공식 문서에 따르면 netplan try는 변경 사항을 임시 적용한 뒤 제한 시간 안에 확인하지 않으면 자동 롤백을 시도합니다. SSH 연결과 DNS 조회가 정상인지 확인한 뒤 설정을 확정하십시오.

필요한 경우 설정을 직접 적용합니다.

sudo netplan apply
resolvectl status

복구 후 정상 작동 확인

DNS 설정을 수정한 뒤에는 이름 해석, APT 저장소 연결, 기본 네트워크 상태를 순서대로 확인합니다.

getent hosts archive.ubuntu.com
getent hosts security.ubuntu.com
resolvectl query archive.ubuntu.com
sudo apt update

getent와 resolvectl query에서 IP 주소가 정상적으로 반환되고 apt update에서 더 이상 Temporary failure resolving이 나타나지 않으면 DNS 문제는 해결된 것입니다.

현재 네트워크와 DNS 상태를 추가로 확인하려면 다음 명령을 사용할 수 있습니다.

sudo netplan status --all
resolvectl status
ip route

자주 발생하는 원인과 해결 방법

APT 프록시 설정도 확인해야 하는 경우

웹 브라우징이나 getent 조회는 정상인데 APT에서만 특정 프록시 호스트에 대해 Temporary failure resolving이 발생한다면 APT 프록시 설정을 확인합니다.

apt-config dump | grep -i proxy
grep -Rni proxy /etc/apt/apt.conf /etc/apt/apt.conf.d 2>/dev/null

더 이상 사용하지 않는 프록시가 설정되어 있다면 해당 설정 파일을 백업한 뒤 수정하거나 비활성화하십시오.

원상복구 방법

Netplan 수정 후 문제가 발생했다면 앞에서 생성한 백업을 기준으로 원래 파일을 복원할 수 있습니다. 먼저 현재 설정을 별도 위치에 보관합니다.

sudo mv /etc/netplan /etc/netplan.after-dns-fix
sudo cp -a /root/netplan-backup /etc/netplan
sudo netplan generate
sudo netplan try

원래 구성으로 네트워크와 DNS가 정상화되었다면 새 설정을 확정합니다. /etc/resolv.conf를 직접 변경했던 경우에는 원래 DNS 관리 방식과 심볼릭 링크 구조를 확인한 뒤 복원하십시오.

관련 비전 IDC 기술자료

• Ubuntu 24.04에서 APT 패키지 저장소 오류를 해결하는 방법
• 비전 IDC 서버 운영 기술자료 전체 보기

공식 참고자료

자주 묻는 질문

Temporary failure resolving 오류가 나오면 APT 저장소 주소를 바꿔야 하나요?

먼저 바꾸지 않는 것이 좋습니다. 이 오류는 일반적으로 저장소 도메인의 DNS 조회가 실패했음을 의미하므로 ip route, resolvectl status, getent hosts를 통해 네트워크와 DNS부터 확인해야 합니다. 저장소 주소 오류는 보통 404, Release 파일 누락 등 다른 형태로 나타납니다.

/etc/resolv.conf에 8.8.8.8을 직접 입력하면 해결되지 않나요?

일시적으로 동작할 수 있지만 Ubuntu 24.04에서 Netplan이나 systemd-resolved가 DNS를 관리하는 환경에서는 다시 덮어써질 수 있습니다. 지속적인 설정은 Netplan 또는 실제 DNS 관리 계층에서 수정하는 것이 좋습니다.

127.0.0.53이 DNS 서버로 표시되는 것은 오류인가요?

반드시 오류는 아닙니다. systemd-resolved의 로컬 DNS 스텁 리졸버를 사용하는 구성에서는 127.0.0.53이 정상적으로 표시될 수 있습니다. 실제 업스트림 DNS 서버는 resolvectl status에서 인터페이스별로 확인하십시오.

재부팅 후 다시 같은 오류가 발생하면 무엇을 확인해야 하나요?

Netplan의 nameservers, DHCP에서 전달되는 DNS, cloud-init이나 호스팅 사업자의 네트워크 자동 설정을 확인해야 합니다. /etc/resolv.conf만 임시로 수정했다면 재부팅 후 원래 상태로 돌아갈 수 있습니다.

DNS는 정상인데 apt update만 실패하면 어떻게 하나요?

오류 메시지에 표시된 실제 호스트 이름을 확인하고 APT 프록시 설정, 서드파티 저장소 주소, 저장소별 DNS 응답 여부를 점검하십시오. 일반적인 APT 저장소 오류는 관련 비전 IDC 기술자료에서 추가로 확인할 수 있습니다.