
쿠버네티스로 관리하던 사이트가 갑자기 접속이 안되는 경우가 있었다.
ERR_EMPTY_RESPONSE....?
응답이 없다니...?
요청을 받는 주체는 살아있는지 궁금해서
kubectl get pods -n want-NameSpace 로 확인해보니 사이트가 올라와있는 파드는 살아있었다.
kubectl edit svc this-service -n want-NameSpace 로 서비스 type을 NodePort로 바꾸거나,
LoadBalancer로 변경(LB로 변경시 ingressClass가 디폴트인 경우 해당 클라우드에서 자동생성)해서 문제가 없다
그렇다면
인그레스 컨트롤러나 기존에 사용중인 로드밸런서 밖에 없다
그러다가 발견한게 로드밸런서 설정에 proxy_protocol이 해제되어있었다.
혹시나 해서 체크해보니 바로 잘 동작했다.
그렇다면 왜? proxy_protocol을 해제하니 안나온것일까?
답은 ingress-controller에 있었다.
ingress-controller는 ingress의 요청대로 들어온 트래픽을 처리해주는 리소스다
nginx ingress-controller, HAproxy, Traefik 같은 것을 사용한다고 한다.
HAproxy만 봐도 proxy가 관련이 있을 거 같은데
회사에서는 nginx ingress controller를 사용하고 있다.


이렇게 사진과 같이 proxy_protocol을 받아 처리한다.
클라이언트의 IP를 TCP의 proxy 헤더로 전송하는 방식이다.
proxy protocol 헤더는 아래와 같은 형태이며
PROXY TCP4 192.168.1.1 1234 10.0.0.1 80\r\n
PROXY 프로토콜의
TCP4 유형으로
192.168.1.1 ip의
1234 포트에서 오는 요청을
ip 가 10.0.0.1의 포트는 80번인 프록시서버로 수행 한다는 의미이다.
nginx ingress controller에서 저런식으로 트래픽을 처리하고 있으니
로드밸런서에서 proxy_protocol을 빼면 PROXY헤더가 아닌 HTTP의 헤더를 보내고
nginx가 이를 읽지못해 client의 IP를 몰라 응답이 없었던것이다.
조만간 이를 테스트 할 수 있는 환경을 구축해봐야겠다.
'nginx' 카테고리의 다른 글
| Nginx 속도 제한 설정 (0) | 2025.07.16 |
|---|---|
| nginx health check (로드밸런서 사용 시 health check 실패인 경우) (0) | 2024.05.09 |
| Nginx 용량 설정 (0) | 2024.04.30 |