ISS-162) Proxmox LXC Nginx 500 에러

1. 🚨 문제 발생: 모든 서비스가 500 에러로 멈췄다

원래는 개인 NAS와 raspberrypi로 내외부 서비스를 운영을 할 때에는 문제없이 운영 중이였습니다. 개인 자료를 보호하기 위해 세그먼트를 나눠 Proxmox(PVE) 환경의 LXC 컨테이너에서 Nginx Proxy Manager(NPM)를 통해 Jenkins, DoEatFit 등 서비스를 운영하다 보니 NPM을 통해 프록시되는 모든 서비스가 500 Internal Server Error를 반환하며 접근이 불가능해졌습니다.

처음엔 DoEatFit 접근 시 500 Internal Server Error를 반환하여 서버 자체 문제인 줄 알았습니다. 근데 NPM web GUI를 접근하니 똑같이 500 Internal Server Error를 반환하더군요. 그래서 재부팅을 하니 정상 작동되어 별 일 아닌줄 알고 방치하였습니다.

근데 일주일정도가가 지나면 다시 발생하더군요.

주요 증상은 다음과 같았습니다.

• LXC 컨테이너(pct restart <CT_ID>)를 재부팅하면 일시적으로 정상화됩니다.

• 하지만 일정 시간이 지나거나 트래픽이 몰리면 어김없이 500 에러가 재발했습니다.

기존 인프라 아키텍처

• Host: Proxmox VE

• Container: LXC (Unprivileged)

• Service: Nginx Proxy Manager (Docker-in-LXC)

• Symptom: NPM을 거치는 모든 서비스(Jenkins, DoEatFit 등)가 500 에러 반환

2. 1차 진단: 범인은 “File Descriptor”

재부팅으로 해결된다는 점에서 처음에는 메모리 부족(OOM Killer)이나 디스크 용량 문제를 의심했습니다.

1. 리소스 확인 (free -h, df -h): 컨테이너 접속 후 확인 결과, 디스크 사용률(23%)과 메모리 모두 매우 여유로웠습니다.

2. 로그 확인 (The Smoking Gun): 리소스 문제가 아니라면 답은 로그에 있습니다. NPM이 설치된 /data/logs/의 error.log를 확인하자, 시스템이 멈춘 시점에 동일한 에러가 반복되고 있었습니다.

[장애 로그 1]

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...
2025/10/26 17:06:18 [crit] 611451#611451: *404543 open() "/usr/local/nginx/proxy_temp/..." failed (24: No file descriptors available) ...
2025/10/26 17:06:56 [crit] 611451#611451: *404569 open() "/html/frontend/index.html" failed (24: No file descriptors available)...

2-1. 원인 분석

로그에 명확히 적혀있더군요 “(24: No file descriptors available)”, 즉 “사용 가능한 파일 디스크립터가 없습니다.” File Descriptor가 뭔지 당황스러웠습니다.

**파일 디스크립터(FD)**는 리눅스 커널이 열린 파일이나 네트워크 연결(소켓)을 식별하기 위해 부여하는 ‘대기표 번호’입니다. Nginx가 새로운 방문자 접속(accept4())을 받거나 파일을 열(open()) 때마다 이 대기표를 소모합니다.

컨테이너의 현재 한도를 확인했습니다.

npmplus:~# ulimit -n
1024

범인은 1024라는 이 낮은 기본값이었습니다. 프록시 서버로서 수많은 동시 접속을 처리해야 할 Nginx에게 고작 1024개의 “창구”만 허용된 것입니다. 1025번째 요청이 오자, “대기표가 소진되었다”며 500 에러를 반환한 것입니다.

2-2. 해결 목표

목표는 ulimit -n 값을 1024에서 넉넉한 표준값인 65536으로 올리는 것이었습니다.

3. 2차 실패: cgroup v2 설정 (존재하지 않는 파일)

Proxmox는 LXC의 리소스 제한을 위해 cgroup(제어 그룹)을 사용합니다. cgroup 설정을 통해 이 한도를 올릴 수 있을 것이라 판단했습니다.

• 시도: PVE 호스트 셸에서 nano /etc/pve/lxc/<CT_ID>.conf 파일을 열고 최신 cgroup v2 구문을 추가했습니다.

  lxc.prlimit.nofile: 65536
  lxc.cgroup2.rlimit.nofile: 65536

• 결과: 컨테이너 시작(pct start <CT_ID>) 실패.

[시도 1 로그]

cgfsng_setup_limits: 3523 No such file or directory - Failed to set "rlimit.nofile"

3-1. 원인 분석

제 PVE 환경은 cgroup v1을 사용 중이었고, cgroup2 설정은 당연히 인식되지 않았습니다.

4. 3차 실패: 비특권 컨테이너의 함정 (1024)

cgroup v1용 구문으로 변경하여 다시 시도했습니다.

• 시도: <CT_ID>.conf 파일의 이전 내용을 지우고 cgroup v1 구문으로 변경했습니다.

  lxc.cgroup.rlimit.nofile: 65536

• 결과: 컨테이너 시작은 성공! 하지만 pct enter <CT_ID>로 들어가 ulimit -n을 확인하니… 여전히 1024였습니다.

4-1. 원인 분석

이것이 이번 장애의 핵심이였습니다. 제 <CT_ID>.conf 설정에는 unprivileged: 1 (비특권 컨테이너) 플래그가 있었습니다.

• **cgroup(제어 그룹)**은 컨테이너의 리소스(CPU, RAM, FD)를 제한합니다.

• 비특권 컨테이너는 보안을 위해 PVE 호스트의 root가 아닌, 별도 매핑된 유저 권한으로 실행됩니다.

• 이 때문에 컨테이너는 호스트 root 유저의 한계를 상속받습니다.

• 컨테이너 설정(lxc.cgroup...)에서 한도를 65536으로 올리려 해도, 호스트의 root 유저 한도가 1024로 막혀있었기 때문에 묵살된 것입니다.

5. ✍️ 최종 해결: “Host”와 “Container” 동시 수정

비특권 컨테이너의 한도를 올리려면, 컨테이너를 실행하는 “호스트(PVE)“의 한계와 “컨테이너”의 설정을 모두 수정해야 했습니다.

모든 작업은 Proxmox 호스트(PVE) 셸에서 수행합니다.

5-1. 1단계: PVE 호스트 한도 상향

PVE 호스트가 컨테이너에 높은 한도를 “허용”하도록 root 유저의 시스템 한도를 수정합니다.

• 작업: nano /etc/security/limits.conf 파일을 엽니다.

• 파일 맨 아래에 다음 두 줄을 추가합니다. (호스트의 root 유저 한도를 65536으로 상향)

root soft nofile 65536
root hard nofile 65536

5-2. 2단계: LXC 컨테이너 설정 수정

이제 호스트가 허용했으니, LXC 컨테이너가 이 한도를 사용하겠다고 prlimit (프로세스 한도)을 통해 명시합니다.

• 작업: nano /etc/pve/lxc/<CT_ID>.conf 파일을 다시 엽니다.

• 시도 2의 lxc.cgroup... 줄을 삭제하고, 다음 한 줄로 변경합니다. (v2에서 시도했던 prlimit 구문이 맞았습니다)

lxc.prlimit.nofile: 65536

5-3. 3단계: Proxmox 호스트(PVE) 재부팅 (필수)

1단계의 limits.conf 설정은 이미 로그인된 세션이 아닌, 시스템 전역에 적용되어야 합니다. Proxmox VE 호스트 자체를 재부팅합니다.

5-4. 최종 확인

PVE 호스트 재부팅 후, LXC 컨테이너(<CT_ID>)를 시작하고 ulimit -n을 다시 확인했습니다.

root@pve:~# pct enter <CT_ID>
~ # ulimit -n
65536

드디어 65536이 적용되었습니다!

6. 결론 및 워크플로우 정상화

NPM 500 에러의 원인은 Nginx가 아닌, **비특권 LXC 컨테이너의 파일 디스크립터(FD) 한도(1024)가 너무 낮았기 때문입니다. File Descriptor는 다음 포스트에서 자세히 알아봤습니다.

Proxmox의 비특권(unprivileged) LXC에서 이 한도를 상향하려면, PVE 호스트의 한계와 LXC의 설정을 모두 수정해야 했습니다.

graph TD
    subgraph "BEFORE (Limit: 1024)"
        PVE["PVE Host (root limit: 1024)"] --"limits.conf"--> L_Root["LXC Root (unprivileged)"]
        L_Root --"inherits"--> Conf["LXC Config (lxc.cgroup...: 65536)"]
        Conf --"is ignored (bottleneck)"--> L_Proc["LXC Process (Nginx)"]
        L_Proc --> O1["ulimit -n: 1024"]
        O1 --> F["💥 500 Error"]
    end

    subgraph "AFTER (Limit: 65536)"
        PVE_A["PVE Host (root limit: 65536)"] --"limits.conf (Reboot)"--> L_Root_A["LXC Root (unprivileged)"]
        L_Root_A --"allows"--> Conf_A["LXC Config (lxc.prlimit...: 65536)"]
        Conf_A --"applies"--> L_Proc_A["LXC Process (Nginx)"]
        L_Proc_A --> O2["ulimit -n: 65536"]
        O2 --> S["✅ 안정"]
    end

이 조치 이후, NPM은 트래픽이 몰리는 상황에서도 (No file descriptors available) 에러 없이 안정적으로 작동하고 있으며, 500 에러는 해결되었습니다.

---