개념 사전/시스템 · 서버 / 웹 서버
개념 사전 · 프로그램

Nginx

엔진엑스 · NGINX

는 정적 파일 제공과 역방향 프록시· 종단 같은 기능을 수행하는 웹 서버이다. listen·으로 사이트를 선택하고 location 규칙으로 URI를 파일이나 뒤쪽 서비스에 연결한다.

밑줄 용어에 마우스를 올리거나, 키보드로 선택하거나, 터치하면 설명을 볼 수 있습니다.

로고: NGINX 공식 자료. 제품 식별을 위해 표시하며 각 상표의 권리는 권리자에게 있습니다.

01무엇이고, 어떤 일을 하나

  • 정적 HTML·CSS·이미지 등을 파일 경로에 대응시켜 응답한다.
  • 여러 도메인의 요청을 서로 다른 server 블록으로 분리한다.
  • HTTP·FastCGI 등의 전달 설정으로 애플리케이션 실행 계층 앞단을 구성한다.
  • master가 설정과 worker 수명을 관리하고 worker의 이벤트 처리로 여러 연결을 진행한다.

02어떤 순서로 동작하나

  1. 준비

    master가 설정을 읽고 worker들을 시작·관리한다. worker는 운영체제의 이벤트 알림을 이용해 여러 연결의 읽기·쓰기 준비 상태를 처리한다.

  2. 연결 수락

    listen 주소·포트에서 연결을 받고 HTTPS이면 단계의 이름과 인증서 조건을 적용한다.

  3. 서버 선택

    요청의 Host 등 이름 정보와 을 연결해 사용할 server 블록을 고른다.

  4. 경로 처리

    URI에 대한 location 선택 뒤 ·· 또는 proxy 설정으로 처리 대상을 정한다.

  5. 응답 반환

    파일을 읽거나 upstream의 응답을 전달하고 접근·오류 로그에 결과를 남긴다. 내부 redirect가 생기면 이 다시 일어날 수 있다.

  6. 설정 세대 교체

    reload 시 master는 새 구성을 검사·적용하고 성공하면 새 worker를 시작한다. 기존 worker는 새 연결 수락을 멈추고 진행 중 요청을 마친 뒤 종료하며, 적용 실패 시 기존 구성으로 계속 동작한다.

03먼저 알아둘 용어와 구성요소

master는 설정 평가와 worker 관리를 맡고, worker는 실제 연결과 요청을 처리한다. 요청마다 새 worker를 하나씩 만드는 모델은 아니다.
소켓이 읽기·쓰기를 진행할 수 있다는 이벤트에 따라 여러 연결의 작업을 이어가는 실행 구조이다. 블로킹 연산의 비용이 자동으로 사라지는 것은 아니다.
는 listen과 으로 서버 블록을 선택하고 URI에 따라 location을 적용한다.
는 정적 파일 경로의 기준을 정하며 단순 매핑에서는 요청 URI를 이어 파일을 찾는다.
는 지정 location 부분을 다른 경로로 대체하는 방식이라 경로 결합 의미가 다르다.
는 지정 후보가 실제 존재하는지 순서대로 보고 마지막 처리로 넘어간다. 정적 사이트에서 $uri $uri/ =404는 요청 파일, 디렉터리 후보를 살펴보고 없으면 404를 돌려주는 예다.
location = /health 같은 정확 일치가 선택되면 그 요청의 location 탐색을 끝낼 수 있다. 파일 이름이 /health라는 뜻이 아니라 URI 선택 조건이다.
선택된 최장 접두사에 가 있으면 그 단계의 탐색을 생략한다. 모든 중첩 location과 새 기능을 이 단순 예의 순서만으로 설명하지 않는다.
LEARN THROUGH PRACTICE

서로 다른 포트의 가상 서버가 문서 루트를 선택하는 과정

listen 포트와 ·index·를 실제 설정에 대입해 요청할 URL과 파일 경로를 계산한다.

실습 구성과 전제

  • 포트 83·84·85를 나눈 설정 화면과 기본 포트의 환영 페이지는 별도 구성 사례다. 환영 페이지를 세 가상 서버의 성공 증거로 사용하지 않는다.
  • 예시 경로는 /srv/lab-a로 재구성한다. 설정을 실제 적용한다면 준비된 실습 서버와 파일 접근 권한이 있어야 한다.

  1. 요청이 들어올 포트와 server 블록을 대응시킨다

    • 화면은 server 블록 세 개에 서로 다른 listen 포트를 둔다. 클라이언트가 어떤 포트로 연결했는지에 따라 먼저 선택 가능한 서버 집합이 달라진다.
    • _는 특별한 모든 이름 매칭 연산자가 아니다. 해당 주소·포트의 default_server 또는 기본 서버 선택과 Host 이름 비교 규칙을 함께 읽어야 한다.
    5/20 - ip/port (virtual host) · 실습·개념 참고 화면 5원본 크기로 보기 ↗
    • 세 블록의 listen 값은 83, 84, 85로 나뉘고 IPv6 listen도 각각 있다.
    • 블록마다 root 경로가 다르고 index index.html, try_files $uri $uri/ =404가 반복된다.
    확인 기준

    포트를 생략한 http URL은 보통 80으로 연결하므로 83·84·85 서버 확인과 다르다.

  2. URI를 문서 루트 아래 파일로 계산한다

    • 재구성 설정에서 /guide.html은 /srv/lab-a/guide.html로 연결된다. / 요청은 디렉터리와 index 처리까지 이어지므로 파일 요청과 처리 경로가 다를 수 있다.
    • 는 정해진 경로에 후보가 존재하는지 확인하고 모두 없으면 지정한 404로 끝낸다. 파일 존재 외에도 웹 서버 계정의 경로 검색·읽기 권한이 필요하다.
    server {
    listen 8083;
    server_name lab.example.test;
    root /srv/lab-a;
    index index.html;
    location / {
        try_files $uri $uri/ =404;
    }
}

    8083과 /srv/lab-a로 재구성한 독립 server 예시다.

    확인 기준

    요청 URL과 예상 파일 경로를 먼저 적고 실제 파일·권한·접근 로그를 대조한다. 404와 접근 거부를 같은 문제로 처리하지 않는다.

  3. 응답 화면이 어느 요청을 검증했는지 한정한다

    • 환영 페이지는 해당 URL에서 기본 문서가 응답한 결과다. 사용자별 나 다른 listen 포트가 올바르다는 결과로 확대하지 않는다.
    • 구성 검사 후 해당 포트와 Host를 지정해 요청하고 예상 문서의 고유 내용을 확인한다. -t 성공은 문법·참조 파일 검사이며 모든 URL의 정상 응답을 보장하지 않는다.
    bash
    sudo nginx -t
curl -i -H "Host: lab.example.test" http://127.0.0.1:8083/guide.html

    재구성한 포트와 Host를 명시해 실제 문서 응답을 확인한다.

    LEMP - Ubuntu · 실습·개념 참고 화면 1원본 크기로 보기 ↗
    • 브라우저에는 Nginx 기본 환영 문서가 보인다.
    • 주소는 별도 사용자 포트 구분 없이 기본 웹 요청 형태이므로 앞의 83·84·85 블록을 직접 검증한 화면은 아니다.
    확인 기준

    기본 환영 페이지만 나오면 실제 요청의 포트·Host와 선택된 서버를 먼저 확인한다.

실습에서 확인한 동작 원리

  • 가상 서버 선택과 파일 경로 계산은 서로 다른 처리 단계다.
  • 기본 페이지 한 장의 성공을 모든 포트·도메인·문서 루트의 성공으로 확대하지 않는다.
관련 개념·전체 실습 화면 이어서 읽기 →
동작·명령 참고 문서
LEARN THROUGH PRACTICE

proxy_pass의 URI 유무로 백엔드 요청 경로 비교하기

upstream 선택과 URI 치환을 분리하여 같은 클라이언트 요청이 백엔드에 어떤 경로로 전달되는지 계산한다.

실습 구성과 전제

  • 세 사진은 upstream 구성과 서로 다른 proxy_pass 설정 예시다. 두 location 설정을 동시에 적용한 단일 서버 결과가 아니다.
  • 일반적인 prefix location을 다룬다. location·변수 기반 proxy_pass·rewrite가 섞인 경우는 별도 규칙을 확인해야 한다.

  1. upstream은 목적 서버 집합을 정의한다

    • 사진의 upstream에는 네 서버가 나열되고 proxy_pass에서 그 그룹 이름을 사용한다. 그룹 선택은 목적 백엔드에 관한 것이며 URI 경로 치환 자체와는 구별된다.
    • 서버에 포트를 생략한 이 HTTP 설정은 기본 80을 사용한다. 각 서버가 실제 어떤 경로에 응답하는지는 애플리케이션 설정과 요청 로그로 확인해야 한다.
    역방향 프록시 경로 전달원본 크기로 보기 ↗
    • upstream my_python_apps 블록에 네 server 행이 나열된다.
    • 각 server 행에는 주소가 있고 별도 포트가 표시되지 않는다.
    확인 기준

    그룹에 등록되었다는 사실만으로 각 서버가 정상이라고 단정하지 않는다. 구성과 실제 연결·응답을 대조한다.

  2. URI 없는 proxy_pass는 기존 경로를 전달한다

    • 첫 location 예시는 /에 대해 proxy_pass http://my_python_apps;를 사용한다. URI를 붙이지 않은 이 단순 구성에서 //item?x=1 요청은 백엔드에도 //item?x=1로 전달된다.
    • 일반 prefix /는 //뿐 아니라 /rrx 같은 문자열에도 맞을 수 있다. 경로 경계를 원한다면 trailing slash와 별도 exact location 설계를 고려한다.
    역방향 프록시 경로 전달원본 크기로 보기 ↗
    • location /rr 블록 안의 proxy_pass는 upstream 이름 뒤 곧바로 세미콜론으로 끝난다.
    • upstream 주소 뒤에 /haha 같은 URI 부분이 없다는 것이 다음 사진과의 차이다.
    확인 기준

    백엔드 404가 나오면 연결 실패로 단정하기 전에 백엔드가 받은 경로를 확인한다.

  3. URI가 있으면 일치한 prefix를 치환한다

    • 다음 사진의 proxy_pass는 /haha를 붙인다. 일반 prefix /에 //item?x=1이 들어오면 일치한 / 부분을 /haha로 바꾼 /haha/item?x=1이 전달되는 구성을 읽을 수 있다.
    • 슬래시 한 개도 결과 경로에 영향을 준다. 재구성 예시처럼 location //와 proxy_pass /api/를 짝지으면 //item이 /api/item으로 매핑된다.
    location /rr/ {
    proxy_pass http://lab_backend/api/;
}

    재구성 예시: //item?x=1 → /api/item?x=1. lab_backend는 준비한 upstream 이름이다.

    역방향 프록시 경로 전달원본 크기로 보기 ↗
    • proxy_pass의 upstream 뒤에 /haha가 추가되어 있다.
    • location은 앞 사진처럼 /rr이므로 목적 서버 집합보다 URI 치환 여부가 핵심 차이다.
    확인 기준

    쿼리 문자열·정규화·rewrite 등 추가 설정이 없다면 계산한 경로를 백엔드 접근 로그에서 확인한다.

실습에서 확인한 동작 원리

  • upstream은 서버 집합을, proxy_pass의 URI 부분은 전달 경로의 치환을 결정한다.
  • 프록시 앞의 URL과 백엔드 접근 로그를 연결하면 정상 연결 뒤 404가 발생하는 이유를 설명할 수 있다.
관련 개념·전체 실습 화면 이어서 읽기 →
동작·명령 참고 문서

04예제로 따라가기

  • /srv/site에서 URI /assets/logo.png는 단순 매핑 시 /srv/site/assets/logo.png가 된다.
  • location /assets/에 /srv/static/을 쓰면 같은 요청은 /srv/static/logo.png에 대응한다.
  • $uri $uri/ =404는 요청 파일·디렉터리 후보를 검사하고 없으면 404를 반환하므로 모든 경로를 index.html로 숨기는 구성과 다르다.
  • reload 직후 서로 다른 세대의 worker가 함께 보일 수 있다. 이전 worker가 진행 중 요청을 마치는 구간이므로 PID가 여러 개라는 이유만으로 중복 설치라고 판단하지 않는다.

05혼동하기 쉬운 점과 확인 기준

  • -t나 apachectl configtest는 설정 파싱·일부 자원 접근을 검사한다. 모든 Host·URI·인증·백엔드 응답을 실제로 실행해 검증하는 것은 아니다.
  • 같은 IP에서 한 이름만 실패하면 Host·SNI·/ServerName과 기본 사이트를 대조한다. 가 같은 IP를 돌려줘도 사이트 선택이 동일하지 않을 수 있다.
  • reload 후에도 기존 연결·작업자가 이전 요청을 처리하는 구간이 있을 수 있다. 설정 파일 저장 시각과 실제 요청을 처리한 ·로그를 구별해 변화의 범위를 판단한다.

06상세 노트 · 실습 자료

헤더 구조, 설정 예시, 수치 계산과 수업 캡처는 아래 노트에서 이어집니다.

Apache·Nginx와 웹 서버 운영웹 서버는 요청을 받을 주소와 사이트를 선택하고 정적 파일을 제공하거나 애플리케이션으로 요청을 전달합니다.상세 노트 읽기 →정방향·역방향 프록시와 캐시프록시가 누구를 대신해 요청을 전달하는지 구분하면 접근 제어, TLS 종료, 캐시와 실제 클라이언트 주소를 이해하기 쉽습니다.상세 노트 읽기 →PHP·WAS와 웹 애플리케이션 실행 계층웹 서버와 애플리케이션 실행기를 구분하고 요청이 프로그램 코드와 데이터베이스까지 전달되는 흐름을 이해합니다.상세 노트 읽기 →
READ · OBSERVE · CONNECT

함께 보는 학습 자료

아래 공식 자료를 본문의 개념·예제와 함께 읽어 보세요. 자료별로 확인할 위치와 관찰할 내용을 적었습니다.

실습 가이드

Nginx 설정·reload·정적 파일·FastCGI 입문

Starting, Stopping, and Reloading Configuration에서 worker 세대 교체를 읽고 Serving Static Content의 URI→파일 경로를 직접 계산한다. 마지막 FastCGI 절에서 앱 실행기와의 경계를 확인한다.

읽으면서 확인할 것
  • 설정 적용 실패 때 기존 worker가 계속 처리하는 경로
  • 에 URI가 붙어 실제 경로가 되는 계산
  • proxy_pass와 fastcgi_pass가 연결하는 뒤쪽 서비스의 차이

공식 문서 · 표준

기초 개념과 동작 설명을 대조한 자료입니다. 제품 버전과 실제 설정에 따른 차이는 본문 및 원문에서 확인하세요.