nginx 동시접속 처리량 계산기
worker_processes와 worker_connections을 넣으면 nginx가 이론상 처리할 수 있는 최대 동시접속 수를 계산합니다. 리버스 프록시면 실효 용량이 절반으로 줄어듭니다.
auto로 두면 보통 CPU 코어 수와 같습니다. 그 숫자를 넣으세요.
nginx.conf의 events 블록에 있는 값입니다. 기본값은 512입니다.
실효 최대 동시 클라이언트
2,048개
이론상 최대 4,096개 연결 중
이론상 최대 연결4,096개
실효 최대 클라이언트2,048개
권장 worker_rlimit_nofile2,048 이상
리버스 프록시는 클라이언트 쪽 연결과 백엔드 쪽 연결을 동시에 물어 연결 두 개를 씁니다. 그래서 실효 최대 클라이언트 수는 이론상 최대치의 절반입니다.
워커 프로세스가 실제로 열 수 있는 파일(소켓 포함) 개수가 OS 레벨에서 제한돼 있습니다. 이 한도(worker_rlimit_nofile)가 worker_connections보다 작으면 이론상 최대치에 도달하기 전에 「Too many open files」 오류가 납니다.
사용 방법
- 1worker_processes 값을 입력합니다(auto면 실제 CPU 코어 수).
- 2worker_connections 값을 입력합니다(기본값 512).
- 3nginx가 리버스 프록시(백엔드로 요청을 넘기는 구성)인지 고릅니다.
- 4이론상 최대 동시접속과, 리버스 프록시 보정을 반영한 실효 최대 클라이언트 수를 확인합니다.
자주 묻는 질문
max_clients = worker_processes × worker_connections입니다. 예를 들어 4코어에 worker_connections 4096이면 이론상 16,384개 연결을 동시에 처리할 수 있습니다.
정적 파일만 서빙하면 클라이언트 하나당 연결 하나만 씁니다. 하지만 리버스 프록시로 백엔드에 요청을 넘기면 클라이언트 쪽 연결과 백엔드 쪽 연결을 동시에 물어 연결 두 개를 씁니다. 그래서 실제로 처리할 수 있는 클라이언트 수는 이론치의 절반입니다.
워커 프로세스가 실제로 열 수 있는 파일(소켓 포함) 개수가 OS 레벨에서 제한돼 있습니다. 이 한도가 계산된 연결 수보다 작으면 이론상 최대치에 도달하기 전에 "Too many open files" 오류가 납니다. worker_connections 이상(리버스 프록시면 그 두 배 이상)으로 맞춰야 합니다.
알아두면 좋은 점
- netdata.cloud·getpagespeed.com 등 nginx 튜닝 자료를 교차확인한 공식(max_clients = worker_processes × worker_connections)과 리버스 프록시 보정입니다.
- 이론상 최대치이며, 실제로는 CPU·메모리·백엔드 응답 속도 등에 따라 더 낮아질 수 있습니다.
- 실제 worker_rlimit_nofile·OS ulimit 설정 방법은 다루지 않습니다.
함께 보면 좋은 도구
nginx locationlocation 블록들과 요청 URI를 넣으면 nginx가 어느 블록을 고르는지 판정하고 그 이유를 알려줍니다.gitignore 판정.gitignore 규칙과 경로를 넣으면 그 파일이 무시되는지, 어느 줄이 마지막으로 이겼는지 알려줍니다.울프람 규칙규칙 번호 0~255를 8비트로 풀어 세 칸 이웃에 대응시키고 세대를 쌓아 무늬를 그립니다.2-SAT「둘 중 하나는 참」인 조건을 여럿 넣으면 참·거짓 배정이 가능한지 판정하고 배정을 하나 찾아 줍니다.2의 보수 변환N비트 폭에서 정수를 2의 보수 이진 표현으로 바꿔 줍니다.
마지막 검증: 2026년 9월 5일 · 결과는 참고용 추정치입니다.