ISS-162) Proxmox LXC Nginx 500 에러

1. 개요

개인 NAS와 Raspberry Pi로 내외부 서비스를 운영하다가, 리소스 및 보안 분리를 위해 Proxmox VE(PVE) 환경의 LXC 컨테이너로 이전하여 Nginx Proxy Manager(NPM)를 구축했습니다. 그러나 어느 날부터 Jenkins, DoEatFit 등 NPM을 통해 프록시되는 모든 서비스가 일제히 500 Internal Server Error를 반환하며 완전히 멈춰 서는 장애가 발생했습니다. 처음에는 일시적인 현상인 줄 알고 컨테이너를 재부팅했더니 정상 작동했으나, 약 1주일 정도 지나 트래픽이 누적되면 어김없이 재발하더군요. 분석 결과 Proxmox 비특권 컨테이너의 제한된 파일 디스크립터(File Descriptor) 기본 한도가 원인이었으며, 호스트와 컨테이너 설정을 동시에 상향 조정함으로써 이 복잡한 인프라 트러블슈팅을 영구적으로 극복해 냈습니다. 그 해결 여정을 상세히 안내해 드릴게요.

---

2. 핵심 내용

2-1. 🚨 문제 현상 및 원인 분석

• 문제 현상:

  • NPM을 거치는 DoEatFit 및 Jenkins를 포함한 모든 서비스가 일주일 간격으로 500 Internal Server Error를 응답하며 정지했습니다.
  • 컨테이너나 호스트를 재부팅하면 일시적으로 풀리지만, 일정 시간이 흐르면 재차 500 에러가 터져 나오는 상태였습니다. 디스크 공간(df -h)과 RAM 용량(free -h)은 20% 내외로 지나치게 넉넉했습니다.

• 원인 분석 (File Descriptor 대기표 고갈):

  • NPM 로그 디렉토리 /data/logs/error.log에서 명확한 원인 단서를 포착했습니다.

  2025/10/26 17:01:03 [crit] 611451#611451: accept4() failed (24: No file descriptors available)
  2025/10/26 17:02:03 [alert] 611451#611451: *404498 socket() failed (24: No file descriptors available) while connecting to upstream...

  • 로그의 (24: No file descriptors available) 메시지는 시스템이 할당할 수 있는 파일 디스크립터(FD)가 바닥났음을 알리고 있었습니다.
  • 리눅스에서 파일 디스크립터는 프로세스가 열린 파일이나 네트워크 소켓 연결을 제어할 때 부여받는 ‘대기표 번호’와 같습니다. Nginx가 새로운 클라이언트 요청을 접수하거나 백엔드 서버와 통신할 때마다 이 FD가 하나씩 소모됩니다.
  • 컨테이너 내부의 기본 한도를 ulimit -n으로 확인해 보니 고작 **1024**로 지정되어 있었습니다. 동시 접속량이 몰리고 정적 리소스 요청이 급증하자 순식간에 1024개의 대기표가 고갈되었고, 1025번째 사용자부터는 아예 소켓을 열지 못해 500 에러를 내려보냈던 것입니다.

2-2. 💡 장애 해결을 위한 삽질과 최종 해결책

• 1단계 시도: cgroup v2 구문 주입 실패:
  • PVE 호스트에서 /etc/pve/lxc/<CT_ID>.conf에 최신 lxc.cgroup2.rlimit.nofile를 설정했으나 컨테이너가 켜지지도 않았습니다. 분석해 보니 해당 노드가 구형 cgroup v1 모드로 돌고 있었기 때문이었습니다.
• 2단계 시도: 비특권 컨테이너 한계 봉착:
  • cgroup v1에 맞게 lxc.cgroup.rlimit.nofile: 65536으로 변경해 컨테이너 부팅은 성공했으나, 안에서 ulimit -n을 쳐 보니 여전히 1024로 변함이 없었습니다.
  • 컨테이너 설정에 기재된 unprivileged: 1 (비특권 컨테이너) 옵션이 문제였습니다. 비특권 컨테이너는 보안을 위해 호스트의 특정 일반 사용자 권한을 매핑받아 돌기 때문에, 호스트 root 사용자의 FD 상계 한도(1024) 이상으로는 절대로 컨테이너 한도를 끌어올릴 수 없는 구조적 바틀넥이 존재했습니다.
• 3단계: 최종 영구 해결책 (호스트와 컨테이너 동시 상향):
  • 결국 PVE 호스트의 허용 한계선과 LXC 컨테이너 설정치 양쪽을 모조리 뚫어주어야만 했습니다.

graph TD
    subgraph "기존 상황 (Limit: 1024 병목)"
        PVE["PVE Host (root FD limit: 1024)"] --"limits.conf"--> L_Root["LXC Root (비특권)"]
        L_Root --"상속 및 상한 차단"--> Conf["LXC Config (65536 설정)"]
        Conf --"무시됨 (1024 병목)"--> L_Proc["Nginx 프로세스"]
        L_Proc --> O1["ulimit -n: 1024"]
        O1 --> F["💥 500 장애 발생"]
    end

    subgraph "개선 상황 (Limit: 65536 확보)"
        PVE_A["PVE Host (root FD limit: 65536)"] --"limits.conf 수정 후 재부팅"--> L_Root_A["LXC Root (비특권)"]
        L_Root_A --"승인 및 전달"--> Conf_A["LXC Config (lxc.prlimit.nofile)"]
        Conf_A --"정상 주입"--> L_Proc_A["Nginx 프로세스"]
        L_Proc_A --> O2["ulimit -n: 65536"]
        O2 --> S["✅ 인프라 초안정"]
    end

1. 호스트(PVE) limits 설정: 호스트 셸에서 /etc/security/limits.conf 파일 최하단에 root 유저 한도를 넉넉하게 적어줍니다.

   root soft nofile 65536
   root hard nofile 65536

2. LXC 컨테이너 설정 튜닝: /etc/pve/lxc/<CT_ID>.conf에 prlimit 전용 옵션을 주입합니다.

   lxc.prlimit.nofile: 65536

3. 호스트 전면 재부팅 및 반영: 호스트 세션에 수정한 전역 limits.conf 값이 완전히 주입되도록 Proxmox 호스트 전체를 1회 재부팅해 준 뒤 컨테이너를 가동했습니다.

2-3. ✅ 결과 검증 및 모던 오픈소스 라이브러리 검토

• 결과 검증:

  • 호스트 재부팅 완료 후 LXC 컨테이너 내부로 진입하여 한도를 조회했습니다.

  pct enter <CT_ID>
  ulimit -n
  # 출력: 65536

  • 파일 디스크립터 한계선이 정상적으로 64배 이상 대폭 늘어났음을 성공적으로 검증했습니다! 이후 트래픽 유입이나 장기 운용 시에도 무의미한 500 Internal Server Error 발생 없이 매우 부드럽고 든든하게 패킷을 전달하고 있습니다.

• 추천 오픈소스 라이브러리 및 인프라 도구 검토:

  1. Prometheus Node Exporter & Grafana
     • 평가: 파일 디스크립터가 고갈되기 직전 임계치를 조기에 감지하여 슬랙(Slack) 등으로 알림을 주는 모니터링 환경을 강력히 제안합니다. node_filefd_allocated 메트릭을 추적하면 인프라 불시 불능을 미리 대비할 수 있어 무척 유용합니다.
  2. Traefik Proxy
     • 평가: 만약 Nginx Proxy Manager(NPM)의 정적 설정 및 도커 컴포즈 의존에서 벗어나, 컨테이너 메타데이터 라벨 기반으로 동적인 라우팅과 SSL 자동 발급을 완전히 현대화하고 싶다면 Go 언어로 작성된 경량 리버스 프록시 Traefik을 훌륭한 대안 기술로 추천해 드립니다.

---