#03 Nginx Reverse Proxy(프록시) 서버 구축

안녕하세요. TAK 입니다:)

 

이번 포스팅은 Nginx Reverse Proxy(프록시) 서버 구축을 목표로 합니다 .🤞

 

Nginx Reverse Proxy(프록시) 서버 구축을 통해 어떻게 동작되는지, 어떻게 활용되는지 확인해 보겠습니다!

 

"#01 Proxy(프록시) 서버란?" & "#02 Squid Forward Proxy(프록시) 서버 구축" 이어지는 내용으로 참고해주세요!

#01 Proxy(프록시) 서버란?

#02 Squid Forward Proxy(프록시) 서버 구축

 

그럼 시작하겠습니다!

---

Contents

1. Reverse Proxy

https://cf-assets.www.cloudflare.com/slt3lc6tev37/3msJRtqxDysQslvrKvEf8x/f7f54c9a2cad3e4586f58e8e0e305389/reverse_proxy_flow.png

 

Reverse Proxy는 서버 쪽에 위치하여 클라이언트 요청을 받아 실제 서버로 전달하고, 서버의 응답을 클라이언트에게 반환하는 역할을 합니다. 

 

그림에서는 origin server 는 내부 네트워크에 위한 서버를 의미하며, Proxy Server는 내부 혹은 DMZ 네트워크에 위치합니다.

 

이는 내부 서버를 보호하고, 로드 밸런싱, SSL 암호화, 캐싱 등의 기능을 제공하기 위해 사용됩니다.

 

1-1. Nginx Reverse Proxy

실제 구축 실습은 Nginx Reverse Proxy를 사용합니다.

 

Nginx Reverse Proxy는 위에 설명한 일반적인 Reverse Proxy의 클라이언트(사용자)와 웹 서버 간 중개자 역할을 하는 서버입니다. 이러한 일반적인 기능 이외 웹 서버로 향하는 요청에 대한 부하를 분산시키고, 내부 서버의 IP가 노출되지 않도록 보호하는 등 다양한 기능을 수행할 수 있습니다.

 

주요 특징은 다음과 같습니다.

• 트래픽 분산 (Traffic Distribution)
  • 로드 밸런싱 (Load Balancing)
    • Nginx는 여러 백엔드 서버 사이에서 트래픽을 분산하여 로드를 균등하게 나누어 처리합니다.
    • 로드 밸런싱 알고리즘으로는 라운드 로빈, 최소 연결, IP 해시 등을 지원합니다.
    • 이를 통해 서버의 성능을 향상하고 응답 시간을 줄일 수 있습니다.
  • 서버 상태 모니터링
    • Nginx는 백엔드 서버의 상태를 모니터링하여, 응답이 느리거나 실패한 서버로의 요청을 자동으로 조정합니다.
• 콘텐츠 캐싱 (Content Caching)
  • 정적 및 동적 콘텐츠 캐싱 (Caching)
    • Nginx는 정적 파일 및 동적 콘텐츠의 캐싱을 지원합니다.
    • 자주 요청되는 콘텐츠를 캐시 하고, 서버의 부하를 줄이며, 클라이언트(사용자)의 요청에 대한 응답 속도를 향상합니다.
• SSL/TLS 암호화 종료 (SSL/TLS Termination):
  • Nginx는 SSL/TLS 암호화 및 복호화를 처리할 수 있으며, 이를 통해 백엔드 서버는 암호화되지 않은 트래픽만 처리할 수 있습니다.
  • 이는 서버의 성능을 향상하고, SSL/TLS 인증서 관리를 중앙화할 수 있게 해 줍니다.
• URL 재작성 및 리다이렉션 (URL Rewriting and Redirection):
  • Nginx는 요청 URL을 재작성하거나 리다이렉션 할 수 있는 기능을 제공합니다.
  • 이를 통해 URL 구조를 변경하거나, 특정 URL 패턴을 다른 URL로 전달할 수 있습니다.
• 보안 (Security):
  • Nginx는 IP 주소 차단, 인증, 접근 제어 등을 통해 보안을 강화할 수 있습니다.
  • 또한, 웹 애플리케이션 방화벽(WAF) 기능과 같은 보안 기능을 통해 악성 트래픽을 차단할 수 있습니다.
• 압축 (Compression):
  • Nginx는 HTTP 응답을 압축하여 대역폭을 절약하고 응답 속도를 향상할 수 있습니다.
  • Gzip 압축을 사용하여 콘텐츠를 압축하고 전송합니다.
• 고가용성 (High Availability):
  • Nginx는 고가용성 아키텍처를 지원하여 시스템의 안정성을 높일 수 있습니다.
  • 여러 Nginx 인스턴스를 클러스터링 하여 장애 발생 시 서비스가 계속 유지되도록 할 수 있습니다.
• 정적 콘텐츠 제공 (Static Content Serving):
  • Nginx는 정적 파일(예: 이미지, CSS, JavaScript 등)을 매우 효율적으로 제공할 수 있습니다.
  • 정적 콘텐츠 제공을 통해 백엔드 서버의 부하를 줄일 수 있습니다.
• 모니터링 및 로깅 (Monitoring and Logging):
  • Nginx는 상세한 액세스 로그와 오류 로그를 기록하여 모니터링과 문제 해결에 도움을 줍니다.
  • 다양한 로그 포맷과 로그 분석 도구를 지원합니다.
    
    

1-2. 구성도

이번 Reverse Proxy 실습은 Azure 환경에서 진행합니다.

 

위 그림과 같이 클라이언트(사용자)가 인터넷을 통해 Target 서버인 Server X, Y에 요청을 할 때,

Nginx Reverse Proxy를 통해 전달될 수 있도록 하는 구성(중계)하며, 응답도 마찬가지로 해당 Proxy 서버를 통해서 전달됩니다.

 

이 과정에서 Target 서버인 Server X, Y의 정보(ex. IP)의 노출 없이 진행됩니다.

 

각 서버의 상세 내역은 다음과 같습니다.

• VM 정보(상세 Spec은 테스트이기에 가장 저렴하게 맞추시면 됩니다.)
  • Client(User) : 외부 인터넷을 통한 요청이기 때문에 로컬 호스트, 즉 대부분이 사용하는 윈도우 환경
  • Reverse Proxy(Nginx) : Linux(Ubuntu 24.04)
  • Server X : Linux(Ubuntu 24.04), API 및 정적 콘텐츠 서버
  • Server Y : Linux(Ubuntu 24.04), DB(MySQL) 서버
• [내부 네트워크]라고 함은 "인증 및 인가되지 않은 액세스는 불가하며, 외부 통신을 제한한다"라는 가정이 전제됩니다.
• Forward Proxy는 DMZ 구간으로 배포된 서버이며, 내/외부 네트워크 중간에 위치하여 제약 사항이 존재합니다.
  

1-2-1. 네트워크 구성

위 구성도를 보면, Proxy 와 서버 간 네트워크 대역이 다름을 확인할 수 있습니다.

 

정확히 Proxy는 DMZ(혹은 Hub) 구간에 배포되어 중계 역할을 하는 서비이기에, Target 서버와 서로 다른 네트워크 대역으로 구분하였습니다.

다만, Proxy와 Target 서버 간 통신을 위해 VNET Peering 을 통해 서로 다른 대역의 가상 네트워크를 연결을 진행합니다. 또한, ACL 역할을 하는 NSG(Network Security Group) 규칙을 통해 IP, Port 에 대해 보다 상세히 제어해 보도록 하겠습니다.

 

 

1-3. Nginx Reverse Proxy 구축

1-3-1. Nginx 설치

Nginx Reverse Proxy라는 것은 결국 Nginx 가 역방향 프록시 기능과 역할을 수행할 수 있음을 의미합니다.

따라서, 설치 자체는 일반적인 Nginx를 설치하는 것과 동일합니다.

이후, 역방향 프록시 기능과 역할을 수행할 수 있도록 서버의 구성을 설정하면 되는 구조입니다.

• apt를 통한 Nginx 설치

sudo apt update
sudo apt install nginx -y

• 설치 확인(System 등록 및 curl 명령어)

 

**Target 서버 구성

이번 실습은 Nginx Reverse Proxy 대해 초점이 맞춰있습니다.

따라서, Target 서버 구성에 대해 자세히 다루지 않습니다.

 

간략히 정리하자면 다음과 같습니다.

- API 서버 : Flask 사용하여 API 요청에 대한 값 응답 구성(메시지, 정적 파일)

- DB 서버 : MySQL 설치하였고, DBA가 Tools(DBeaver 등)을 사용하여, 데이터 조회 혹은 활용(Join)을 하기 위한 간단한 데이터베이스, 테이블, 데이터 생성

 

1-3-2. Nginx Reverse Proxy 구성

Nginx의 전역 설정 파일은 /etc/nginx/nginx.conf 입니다. 이는 서버 전체의 기본 설정을 정의하는 곳으로  워커 프로세스 수, 로그 파일 위치, 기본 사용자 및 그룹, 타임아웃 등 성능과 보안 관련 전역 옵션이 포함됩니다.

 

또한, 전역적으로 사용할 HTTP 프로토콜 관련 설정을 정의합니다. 여기서 정의된 값들은 모든 서버 블록에 적용될 수 있으며, 서버별로 별도로 설정한 값이 없다면 기본적으로 사용됩니다.

 

해당 HTTP 블록에서 포함(include)시키는 부분인 /etc/nginx/sites-enabled/* 을 통해 개별 서버 설정 파일을 포함하는데, 이는 디렉터리 내의 파일들은 서버별 세부 설정을 관리합니다. 여기에는 각 도메인에 대한 포트, SSL 인증서, 리버스 프록시 설정 등이 포함됩니다.

 

즉, 사이트별 설정은 sites-available 디렉토리에 위치한 개별 설정 파일에서 관리되는 구조이며, 해당 설정(/etc/nginx/sites-enabled/*)에서 이번에 구성하고자 하는 Reverse Proxy 설정 및 관리가 이뤄집니다.

 

기본 값인 default 파일 구성은 다음과 같습니다.

# /etc/nginx/sites-available/default

##
# You should look at the following URL's in order to grasp a solid understanding
# of Nginx configuration files in order to fully unleash the power of Nginx.
# https://www.nginx.com/resources/wiki/start/
# https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/
# https://wiki.debian.org/Nginx/DirectoryStructure
#
# In most cases, administrators will remove this file from sites-enabled/ and
# leave it as reference inside of sites-available where it will continue to be
# updated by the nginx packaging team.
#
# This file will automatically load configuration files provided by other
# applications, such as Drupal or Wordpress. These applications will be made
# available underneath a path with that package name, such as /drupal8.
#
# Please see /usr/share/doc/nginx-doc/examples/ for more detailed examples.
##

# Default server configuration
#
server {
        listen 80 default_server;
        listen [::]:80 default_server;

        # SSL configuration
        #
        # listen 443 ssl default_server;
        # listen [::]:443 ssl default_server;
        #
        # Note: You should disable gzip for SSL traffic.
        # See: https://bugs.debian.org/773332
        #
        # Read up on ssl_ciphers to ensure a secure configuration.
        # See: https://bugs.debian.org/765782
        #
        # Self signed certs generated by the ssl-cert package
        # Don't use them in a production server!
        #
        # include snippets/snakeoil.conf;

        root /var/www/html;

        # Add index.php to the list if you are using PHP
        index index.html index.htm index.nginx-debian.html;

        server_name _;

        location / {
                # First attempt to serve request as file, then
                # as directory, then fall back to displaying a 404.
                try_files $uri $uri/ =404;
        }

        # pass PHP scripts to FastCGI server
        #
        #location ~ \.php$ {
        #       include snippets/fastcgi-php.conf;
        #
        #       # With php-fpm (or other unix sockets):
        #       fastcgi_pass unix:/run/php/php7.4-fpm.sock;
        #       # With php-cgi (or other tcp sockets):
        #       fastcgi_pass 127.0.0.1:9000;
        #}

        # deny access to .htaccess files, if Apache's document root
        # concurs with nginx's one
        #
        #location ~ /\.ht {
        #       deny all;
        #}
}


# Virtual Host configuration for example.com
#
# You can move that to a different file under sites-available/ and symlink that
# to sites-enabled/ to enable it.
#
#server {
#       listen 80;
#       listen [::]:80;
#
#       server_name example.com;
#
#       root /var/www/example.com;
#       index index.html;
#
#       location / {
#               try_files $uri $uri/ =404;
#       }
#}

 

해당 구성은 HTTP 요청에 대해 일반적으로 80 포트 기반, 클라이언트의 요청을 처리하는 방법을 정의하고 있습니다.

 

여기서, 추가 및 수정하고자 하는 부분은 다음과 같습니다.

- HTTPS(443) 설정 및 리디렉션

- Target 서버인 API(정적 콘텐츠)에 대한 Reverse Proxy 설정 > location 추가

- HTTP(S) 이외 다른 프로토콜(MySQL Admin 접근용) 처리 > Stream 정의(nginx.conf의 전역 설정)

 

위 항목에 대해 구성 파일별로 정의하겠습니다.

 

하지만, 그전에 Nginx의 모듈의 개념을 잠시 살펴보겠습니다.

 

**NGINX Moduels

a) HTTP 모듈
역할: HTTP 및 HTTPS 프로토콜을 처리하는 모듈입니다.

용도: 주로 웹 트래픽을 처리하며, 웹서버 기능을 제공하거나, 리버스 프록시(Reverse Proxy) 역할을 수행합니다. 정적/동적 콘텐츠를 제공하거나, 프록시 서버로서 백엔드 서버에 요청을 전달합니다.

구성 파일: /etc/nginx/sites-enabled/default와 같은 파일을 사용하여 HTTP 요청을 처리하는 설정을 합니다.

 

b) Server 모듈
역할: Nginx의 기본 단위로, HTTP, HTTPS, TCP/UDP 프로토콜을 사용하는 서비스를 정의할 수 있습니다.

용도: 각 프로토콜에 대한 서버 블록을 정의하며, listen 지시어를 사용해 해당 서버가 어떤 포트를 통해 요청을 수신할지 결정합니다. HTTP와 Stream 모듈에서 Server 블록은 각각의 프로토콜에 맞게 설정됩니다.

 

여기서 a) HTTP 모듈과 b) Server 모듈의 차이점을 정리해 보면 다음과 같습니다.

구분	HTTP 모듈	Server 모듈
역할	HTTP/HTTPS 트래픽을 처리하는 전체적인 설정을 관리함.	하나의 포트와 도메인에 대한 특정 설정을 정의함.
위치	http {} 블록 안에서 정의됨.	http {} 또는 stream {} 블록 안에서 정의됨.
기능	웹 트래픽, 로그 설정, 압축, 캐싱 등 다양한 기능을 지원함.	각 도메인 또는 IP에 대한 트래픽을 처리함. 포트, SSL 설정 등을 포함함.
구조	여러 개의 server {} 블록을 포함할 수 있음.	각 server {} 블록은 하나의 포트와 도메인을 담당함.

 

c) Stream 모듈
역할: TCP와 UDP 프로토콜을 처리하는 모듈입니다. HTTP가 아닌 다른 프로토콜(예: MySQL, Redis, SMTP 등)을 프록시하거나, 라우팅 할 때 사용됩니다.

용도: MySQL, Redis, SSH, SMTP 같은 TCP/UDP 기반 서비스의 트래픽을 프록시할 때 사용됩니다.

구성 파일: 이 모듈은 nginx.conf 파일의 최상위 레벨에 설정해야 합니다. HTTP 모듈과 별개로 처리되므로, HTTP 모듈을 사용하는 sites-enabled/default 같은 파일에서는 이 설정을 사용할 수 없습니다.

 

결과적으로  HTTP 모듈과 Stream 모듈은 서로 다른 트래픽을 처리하므로, 각각의 특성에 맞는 설정을 해야 합니다.

 

1-3-3. /etc/nginx/sites-enabled/*

해당 경로의 파일은 앞서 설명한 것처럼 HTTP(S) 관련 사이트 설정이 포함된 디렉토리로, HTTP 모듈과 관련된 설정만 포함됩니다. 즉, /etc/nginx/sites-enabled/* 디렉토리에서 사용하는 설정 파일들은 HTTP/HTTPS 트래픽을 처리하는 HTTP 모듈을 기반으로 동작합니다. Nginx의 HTTP 모듈은 기본적으로 웹 트래픽(HTTP, HTTPS)을 처리하도록 설계되어 있으며, 이를 통해 TCP/UDP 기반 트래픽을 직접 처리할 수는 없습니다.

 

웹 서비스와 같은 HTTP 기반 트래픽을 처리하며, 일반적으로 server 블록을 사용해 HTTP 요청을 다루며, 정적 파일 제공이나 리버스 프록시 설정을 수행합니다. 각 프로토콜에 대한 서버 블록을 정의하며, listen 지시어를 사용해 해당 서버가 어떤 포트를 통해 요청을 수신할지 결정합니다. HTTP와 Stream 모듈에서 Server 블록은 각각의 프로토콜에 맞게 설정됩니다. 즉, 각 server {} 블록은 하나의 도메인이나 서비스에 대한 설정을 정의합니다. 주로 특정 포트와 도메인에 대한 트래픽을 처리합니다.

 

이를 다음과 같이 설정할 수 있습니다.

 

크게 두 부분으로 나눠 설정하자면,

[# HTTP에서 HTTPS 리디렉션] 은 먼저 HTTP 요청을 80 포트에서 수신하여, 클라이언트가 HTTP 프로토콜을 통해 요청을 보낼 때, 이 서버 블록이 활성화됩니다. 이 설정에서는 모든 HTTP 요청을 HTTPS로 리디렉션 합니다.

 

이후,

[# HTTPS 프록시 설정] 에서는 HTTPS 요청을 처리합니다.

실제 Target 서버 프록시 전, SSL을 사용을 위한 인증 설정을 정의합니다. 이후, 각 서버의 구성에 맞춰 프록시 설정을 합니다.

실제 Target 서버인 API 서버로 프록시 하기 위해, location 설정에 따른 경로별 요청의 헤더 정보를 설정하여 원본 클라이언트의 IP 주소 및 요청 정보를 API 서버에 전달합니다. 이 설정을 통해 API 서버는 클라이언트 요청을 올바르게 인식하고 처리할 수 있습니다.

 

1-3-4. /etc/nginx/nginx.conf 

MySQL 액세스를 위해서는 별도로 TCP/UDP 트래픽을 처리하기 위한 stream 모듈에서 처리해야 합니다.

stream 모듈은 Nginx의 기본 설정 파일에서 설정합니다. 해당 설정은 전체 Nginx 서버의 동작을 정의하며, stream 설정을 통해 TCP/UDP 트래픽을 처리합니다.

 

stream 모듈은 은 HTTP 요청이 아닌 TCP/UDP 프로토콜을 기반으로 하는 트래픽을 다루기 때문에, 이를 사용하여 Nginx를 TCP/UDP 프록시로 구성할 수 있습니다. 예를 들어, MySQL, Redis, PostgreSQL 등 TCP 기반 프로토콜을 프록싱할 수 있습니다.

 

즉, 데이터베이스와 같은 TCP 서비스는 반드시 stream 모듈을 통해 설정해야 하며, HTTP 모듈을 통해서는 설정할 수 없습니다.

 

stream 블록 내 TCP 및 UDP 트래픽을 처리할 수 있는 범위를 정의합니다.

여기서 upstream db_servers 블록을 통해 DB 서버의 IP와 포트를 정의합니다. 이는 클라이언트의 요청이 해당 정보로 전달되도록 합니다. 이후, Server 블록을 통해 클라이언트가 연결할 포트를 설정합니다. 여기서는 listen 3306;을 통해 클라이언트가 MySQL에 접속할 포트를 지정합니다. 클라이언트는 이 포트로 요청을 보내고, Nginx는 이를 수신합니다.

 

proxy_pass 지시어를 통해, 클라이언트의 요청을 실제 데이터베이스 서버로 전달하기 위해 proxy_pass db_servers;를 사용합니다. 이 지시어는 앞서 정의한 upstream 블록으로 설정한 서버로 요청을 포워딩합니다.

 

이렇게 Target 서버 중계를 위한 Proxy 서버의 설정을 마쳤습니다.

 

위 변경사항을 저장하고 Nginx가 올바르게 작동하는지 확인 후, 재시작합니다.

sudo nginx -t

sudo systemctl restart nginx

마음이 편안해지는 초록색~

 

(만약, nginx -t 명령어 실행 시, 에러가 발생한다면 Nginx의 에러 로그(/var/log/nginx/error.log)를 살펴보세요!)

 

마지막으로 위 구성을 통해, 정상적으로 Proxy 서버가 잘 동작하는지 테스트를 진행하겠습니다.

 

1-4. Proxy 테스트

Reverse Proxy를 구성한 이유는 Target 서버를 노출시키지 않고, 클라이언트(사용자)에 대한 요청을 Proxy 서버가 중계하여 응답을 반환하는 통신을 하기 위함입니다.

따라서, 인터넷을 통한 클라이언트의 요청을 Nginx Reverse Proxy에게 전달합니다.

 

우선, 기본 Nginx가 서비스하는 페이지를 확인해 보겠습니다. 

• http://<Nginx-Reverse-Proxy의 IP 혹은 DNS>

 

• Server 블록에 정의한, 리디렉션 설정에 따라 동작
  • 다만, 자체 서명 인증서 발급으로 인해, 신뢰할 수 없는 [인증서가 올바르지 않음]으로 표기
  • [고급] 클릭 후, 보이는 링크로 이

 

• 기본 Nginx 페이지 확인

 

 

1-4-1. API 서버 Proxy 

/etc/nginx/sites-enabled/default 의 Server 블록에서 정의한, URL 경로 구성에 따라 API 서버에 구성 요청이 중계가 잘 되는지 확인해 보겠습니다.

 

• 메시지(GET) : /api/

• 정적 파일 : /static/

 

위 그림들처럼, 클라이언트(사용자)가 인터넷을 통해 HTTP(S) 요청을 보내면, Nginx는 클라이언트로부터 온 요청을 받고, 그 요청을 백엔드 API 서버로 전달하기 위한 프록시 역할을 합니다. 위에서 정의한 설정 파일에 따라 클라이언트의 요청을 처리합니다.

즉, 해당 요청이 Nginx reverse proxy에 도달하고, Nginx가 그 요청을 백엔드의 API 서버로 전달한 뒤 응답을 다시 클라이언트로 반환하는 과정입니다.

 

이제 Nginx Reverse Proxy 서버의 로그를 살펴보겠습니다.

/var/log/nginx/access.log

 

 

위 순서대로 각 URL의 access 로그를 확인해 보면,

클라이언트(사용자)의 정보와 함께 정의된 경로로 요청 정보, 그리고 HTTP 상태 코드(200)가 확인되면서

API 서버가 중계된 요청에 대한 응답(데이터)을 반환하며 Proxy 역할이 잘 수행됨을 확인할 수 있습니다.

 

 

1-4-2. DB 서버 Proxy

/etc/nginx/nginx.conf 의 stream 블록에 정의한 설정에 따라 DB 서버에 접근할 수 있는지 확인해 보겠습니다.

해당 구성은 인터넷을 통해 DB Tool(DBeaver)을 통해 DBA가 접근하여 데이터를 조회하기 위한 가정으로 진행하였습니다.

 

DB의 경우, 서버 내 MySQL을 설치하고 데이터베이스, 테이블, 데이터를 생성한 상태입니다.

또한, 사용자를 추가하고, DB 접근을 위한 적절한 권한을 설정하였습니다.

 

중계의 흐름은 클라이언트가 Nginx에 연결하면, Nginx는 요청을 받아 정의된 upstream 블록을 통해 DB 서버에 전달합니다. 이때 Nginx는 클라이언트의 연결을 DB 서버와 연결하는 중개자 역할을 합니다. 이후, DB 서버는 Nginx로부터 받은 요청을 처리한 후, 결과를 Nginx로 반환합니다. 이 과정에서 DB 서버는 클라이언트의 IP 주소를 모르고 Nginx의 IP 주소만 알고 있습니다.

Nginx는 DB 서버로부터 받은 응답을 클라이언트에게 다시 전달합니다. 이때 클라이언트는 마치 DB 서버와 직접 연결된 것처럼 응답을 받을 수 있습니다.

 

• DBeaver 연결

 

아래 3가지 항목 입력 후, [Test Connection] 을 통해 연결 여부를 확인하고 [완료] 클릭

- Server Host : Nginx Proxy 서버의 IP 혹은 DNS 입력

- Database : Database 이름

- Authentication : 로그인 정보

 

여기서, "Public Key Retrieval is not allowed" 에러 확인 시, [Driver properties] 탭에서 아래 항목을 "True" 변경하면 연결 문제를 해결할 수 있습니다.

 

• 연결 성공

 

• 데이터 조회

 

• Join 쿼리문 실행
  • 위 조회에 실행한 2 테이블 기반, 사용자의 이름과 그들이 주문한 제품 조회

 

 

다만, 위 구성은 access.log에 기록지 않습니다. 

그 이유는 access.log는 기본적으로 HTTP 요청을 기록하도록 설계되어 있습니다. 이 로그 파일은 웹 트래픽을 기록하는 데 초점을 맞추고 있으며, 여기에는 URL, 브라우저 정보, HTTP 상태 코드 등의 HTTP 전용 정보가 포함됩니다.

 

따라서 stream 블록에서 logging을 위한 별도의 구성이 필요합니다. 즉, stream 모듈에 대해서는 별도의 로그 포맷과 로그 파일을 지정해야 합니다.

 

그렇다면, 구성 파일을 아래와 같이 수정합니다.

 

이후, 재연결을 시도하면 다음과 같이 DB 서버에 대한 연결 요청 시에 200 응답 코드를 확인할 수 있습니다.

 

여기서, 쿼리 실행 시 로그가 남지 않는 이유는 Nginx의 stream 모듈이 TCP 연결 자체에 대한 정보를 기록하고, TCP 세션 내부에서 주고받는 쿼리와 같은 애플리케이션 레벨의 데이터는 기본적으로 로그에 포함하지 않기 때문입니다.

 

Nginx의 stream 모듈은 주로 L4 (전송 계층)에서 동작하므로, HTTP처럼 요청과 응답을 각각 기록하는 방식이 아니라, TCP 연결의 시작과 종료만 기록하는 구조입니다.

 

만약, 쿼리 로그가 필요하다면, MySQL 로그 설정 혹은 DBeaver에서 쿼리 로그를 활성화하여 확인할 수 있습니다.

---

이상으로 "#03 Nginx Reverse Proxy(프록시) 서버 구축"  포스팅을 마치겠습니다!

 

제가 #02 Squid Forward Proxy 구축에서 빠른 시일 내 찾아뵙겠다고 말씀드렸지만, 굉장히;; 늦어졌습니다😅

 

다음에도 포스팅도 함께 나눌 수 있는 주제로 돌아오겠습니다!!