오류 해결 · 5 min read · Jan 22, 2026
건강한 업스트림 없음 오류 – 이해, 수정 및 예방에 대한 완벽한 가이드

웹 애플리케이션, API 또는 서비스에서 “건강한 업스트림 없음” 오류가 발생하면, 이는 종종 로드 밸런서 또는 게이트웨이가 요청을 전달할 수 있는 건강한 백엔드 서버 풀을 소진했음을 나타냅니다.
즉, “트래픽 디렉터”가 유효한 대상을 가지고 있지 않으며, 따라서 사용자의 요청은 아무데도 가지 않게 되어 연결 실패, 중단 및 불만족스러운 고객을 초래합니다.
이는 Nginx 리버스 프록시, Kubernetes 클러스터, Docker 컨테이너 또는 VMware vCenter와 같은 가상화된 설정 등 거의 모든 유형의 설정에서 발생할 수 있습니다.
실제 근본 원인은 설정에 따라 다르지만, 일반적으로 잘못된 점은 다음과 같습니다: 업스트림 서비스가 다운되었거나, 건강 검사를 통과하지 못하거나, 잘못된 구성으로 차단되었습니다.
“건강한 업스트림 없음” 오류는 무엇을 의미합니까?
로드 밸런싱 또는 서비스 메쉬 아키텍처의 맥락에서 업스트림은 클라이언트로부터 오는 요청을 처리하는 백엔드 서버 또는 서비스를 나타냅니다.
로드 밸런서 또는 게이트웨이(예: Nginx, Envoy, API Gateway)는 요청에 대한 책임을 져야 할 업스트림 서버를 결정합니다.
구성된 건강 검사가 어떤 업스트림에서도 통과하지 않거나, 어떤 업스트림에도 도달할 수 없는 경우 “건강한 업스트림 없음” 오류가 발생합니다.

이 오류가 발생하는 일반적인 시나리오
느린 응답 또는 잘못된 구성으로 인한 건강 검사 실패.
네트워크 연결 문제로 인해 백엔드 서비스에 접근할 수 없음.
라우팅 규칙이 잘못 구성된 경우, 트래픽이 잘못된 대상으로 이동함.
다양한 시스템에서의 예시
Nginx: [error] no live upstreams while connecting to upstream
Kubernetes: 0/3 nodes are available: 3 node(s) had taints that the pod didn’t tolerate
Docker: service “app” is not healthy
플랫폼 전반의 일반적인 원인
환경에 따라 정확한 이유는 다르지만, 가장 일반적인 원인은 다음과 같습니다:
백엔드 서비스 충돌 또는 종료: 서비스가 중단되거나 충돌하여 더 이상 실행 중인 인스턴스가 없음.
잘못된 건강 검사 설정: 실패할 경우, 로드 밸런서는 건강한 서버를 “다운”으로 간주하여 풀에서 제거함.
DNS 해상도 문제: 백엔드의 도메인 이름을 IP 주소로 해석할 수 없음.
포트 불일치: 백엔드 서비스가 수신하는 잘못된 포트에 대한 업스트림 설정 구성.
네트워크 정책 및 방화벽: 보안 규칙에 의해 차단되어 로드 밸런서가 백엔드와 통신할 수 없음.
인증서 만료: SSL/TLS 구성에서 만료된 인증서는 보안 연결을 방해할 수 있음.
Kubernetes의 포드 스케줄링 또는 노드 오염: 호환되지 않는 노드 조건으로 인해 포드가 실행되지 않을 수 있음.
오류 진단 방법
“건강한 업스트림 없음” 오류를 해결하기 위한 첫 단계는 로드 밸런서, 네트워크 또는 백엔드 서비스 중 어디에서 실패하고 있는지를 확인하는 것입니다.
1단계: 백엔드 가용성 확인
Linux 서비스의 경우: systemctl status
네트워크 포트 확인: netstat -tulpn | grep
2단계: 네트워크 연결 테스트
- 로드 밸런서에서 백엔드로:
# 예시 (실행 전에 자리 표시자를 교체):
curl -v :/ - DNS 해상도 테스트: dig backend.example.com
3단계 – 로그 검토
Nginx: /var/log/nginx/error.log
Kubernetes: kubectl describe pod
Docker: docker logs
vCenter: 인증서 및 서비스 로그
4단계 – 건강 검사 확인
/health 엔드포인트가 적절한 200 OK 또는 유사한 상태를 반환하는지 확인하십시오.
경로와 메서드가 로드 밸런서가 확인하도록 구성된 것인지 확인하십시오.
플랫폼별 수정 방법
A. Nginx
Nginx에서 라이브 업스트림이 없다고 표시되면, 목록은 일반적으로 백엔드 정의 또는 건강 검사 실패와 관련된 문제의 신호입니다.
Nginx 수정 체크리스트:
백엔드 IP/호스트 이름이 올바른지 확인하십시오.
백엔드 서비스가 실행 중이고 접근 가능한지 확인하십시오.
건강 검사 구성을 조정하십시오:
upstream backend {
server backend1.example.com:8080 max_fails=3 fail_timeout=30s;
server backend2.example.com:8080 backup;
}- 선택적으로 활성 건강 검사를 추가하십시오(필요한 경우 Nginx Plus 또는 모듈):
check interval=3000 rise=2 fall=5 timeout=1000 type=http;
check_http_send "HEAD / HTTP/1.0\r\n\r\n";
check_http_expect_alive http_2xx http_3xx;B. Kubernetes
Kubernetes 로드 밸런싱에서는 준비 상태 프로브와 서비스-포드 매핑이 필요합니다.
일반적인 수정 사항:
포드가 실행 중인지 확인하십시오: kubectl get pods
준비 상태 프로브 설정을 확인하십시오:
readinessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 5
periodSeconds: 10서비스 선택기가 포드 레이블과 일치하는지 확인하십시오.
차단된 트래픽에 대한 네트워크 정책을 검사하십시오.
C. Docker
Docker 및 Docker Compose에서 컨테이너의 건강 검사가 통과하면 건강한 것으로 표시됩니다.
수정 단계:
- 컨테이너 건강 상태 검토: docker inspect
docker-compose.yml에서 건강 검사를 구현하거나 수정하십시오:
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost/health"]
interval: 30s
timeout: 10s
retries: 3- 서비스가 실제로 /health 엔드포인트를 제공하는지 확인하십시오.
D. VMware vCenter
종종 이유는 만료된 SSL 인증서 때문일 수 있습니다. 이는 주로 vCenter 사용자와 관련이 있습니다. 인증서가 만료되었는지 확인하는 방법은 다음과 같습니다:
먼저 vCenter Appliance를 시작하십시오.
다음 명령을 실행하십시오: for store in $(/usr/lib/vmware-vmafd/bin/vecs-cli store list | grep -v TRUSTED_ROOT_CRLS); do echo “[*] Store :” $store; /usr/lib/vmware-vmafd/bin/vecs-cli entry list –store $store –text | grep -ie “Alias” -ie “Not After”;done;
이제 Machine_SSL 및 Solution User 인증서가 만료되었는지 확인하십시오. 만료되었다면 교체하십시오.
다음 명령을 PowerShell에서 실행할 수도 있습니다: $VCInstallHome = [System.Environment]::ExpandEnvironmentVariables(“%VMWARE_CIS_HOME%”);foreach ($STORE in & “$VCInstallHome\vmafdd\vecs-cli” store list){Write-host STORE: $STORE;& “$VCInstallHome\vmafdd\vecs-cli” entry list –store $STORE –text | findstr /C:”Alias” /C:”Not After”}
즉각적인 복구 조치
근본 원인을 작업하는 동안 빠른 복원이 필요하다면:
백엔드에서 서비스를 재시도하여 백엔드 서비스의 업데이트된 버전에서 임시 서비스를 제공합니다.
해상도 문제가 있는 경우 DNS 또는 IP 주소를 업데이트하십시오.
업스트림 블록에 백업 서버를 추가하여 임시 처리기로 사용하십시오.
나쁜 건강 검사를 일시적으로 비활성화하십시오(영구적인 해결책은 아님).
건강한 업스트림 없음 오류 예방
예방은 회복력과 가시성에 관한 것입니다:
- 건강 검사 모범 사례
각 서비스는 /health 엔드포인트를 제공할 수 있습니다.
서비스가 실행 중이면 간단한 200 OK로 응답합니다.
이러한 타임아웃 + 재시도 한도는 실제 성능을 나타내야 합니다.
- 중복성
여러 백엔드 인스턴스를 사용하십시오.
항상 최소한 하나의 백업 서버를 준비하십시오.
- 모니터링 및 경고
Prometheus + Grafana, Datadog 또는 New Relic을 사용하여 전체 업스트림 실패 전에 경고할 수 있습니다.
지연 시간, 오류율 및 연결 수를 모니터링하십시오.
- 구성 위생
DNS 기록을 최신 상태로 유지하십시오.
서비스 포트 및 건강 검사 경로를 문서화하십시오.
연쇄 실패를 방지하기 위해 회로 차단기를 사용하십시오.
- 보안 및 네트워크 규칙
방화벽 규칙 및 Kubernetes 네트워크 정책을 정기적으로 검토하십시오.
SSL 인증서를 최신 상태로 유지하십시오.
자주 묻는 질문
서버 접근 없이 이 문제를 수정할 수 있나요?
아니요, 백엔드 또는 구성 문제를 수정하려면 시스템 관리자 또는 개발자여야 합니다.
항상 백엔드 문제인가요?
항상 그런 것은 아니지만 로드 밸런서 또는 DNS 구성 문제일 때는 그렇습니다.
수정하는 데 얼마나 걸리나요?
경미한 잘못된 구성은 몇 분 안에 수정할 수 있으며, 네트워크 또는 확장 문제는 몇 시간이 걸릴 수 있습니다.
전체 실패 전에 성능에 영향을 미치나요?
예, 업스트림 부분 실패는 전체 중단 전에 지연 시간 및 오류율 증가로 이어질 수 있습니다.
어떤 모니터링 도구가 가장 좋나요?
Prometheus + Grafana, Datadog, New Relic 및 기본 클라우드 모니터링 모두 훌륭합니다.
최종 생각
“건강한 업스트림 없음” 오류는 단순한 모호한 버그 이상으로 보입니다. 이는 요청을 처리하는 시스템이 백엔드 인프라에 접근할 수 없음을 나타내는 지표입니다.
최종 사용자에게는 오류 메시지, 관리자에게는 작업 항목입니다. Nginx, Kubernetes, Docker 및 VMware를 실행하든 관계없이 원칙은 동일합니다. 모니터링하고, 구성을 검증하고, 네트워크 접근을 확인하고, 서비스 건강을 검증하십시오.
빠른 수정과 장기 솔루션의 조합을 통해 이 오류가 서비스에 영향을 미칠 가능성을 크게 줄일 수 있습니다.
새 게시물을 받은 편지함에서 받기
스팸은 없습니다. 언제든지 구독 해지 가능합니다.