F5 NGINX Plus 37.0 출시
F5 NGINX Plus 37.0 버전 출시를 발표하게 되어 매우 기쁩니다. 이번 릴리스에는 에이전트 트래픽 모니터링, 새로운 API를 통한 원격 구성 제어, 사용자 지정 변수를 포함한 JSON 형식의 오류 로그, 고정밀 메트릭을 사용한 업스트림 지연 시간 모니터링 등 매우 광범위한 새로운 기능이 포함되어 있습니다.
또한, 제품 수명 주기 계획을 지원하기 위해 NGINX Plus 37.0은 새로운 장기 지원(LTS) 정책에 따라 지원되는 첫 번째 릴리스가 될 것입니다. 왜 R37이 아닌 37.0 릴리스인지 궁금하시죠? LTS 정책 도입으로 NGINX Plus의 버전 관리 방식이 변경되었기 때문입니다 .
NGINX Plus는 언제나처럼 검증되고 신뢰할 수 있는 올인원 소프트웨어 웹 서버, 로드 밸런싱, 리버스 프록시, 콘텐츠 캐시 및 API 게이트웨이인 NGINX 오픈 소스의 최신 기능을 모두 계승합니다. NGINX 오픈 소스 와 NGINX Plus의 최신 기능, 버그 수정 및 보안 패치를 모두 활용하려면 최신 NGINX Plus 릴리스로 업그레이드하는 것을 적극 권장합니다 .
다음은 37.0에서 가장 중요한 업데이트 요약입니다:
에이전트 관찰 가능성 : 실시간 MCP 트래픽 모니터링
NGINX Plus는 새로운 관찰 기능을 통해 에이전트 기반 AI 시대를 맞이할 준비가 되어 있습니다. 이 기능을 통해 팀은 AI 에이전트 활동을 추적 및 모니터링하고, 과도하게 통신하는 에이전트를 식별하고, 오류 발생 가능성이 높은 MCP 도구를 파악하고, MCP 서버 지연 시간을 감지하고, 새롭게 나타나는 AI 애플리케이션 패턴에 대한 문제 해결을 지원할 수 있습니다.
Control API
NGINX Plus 재구성 작업이 훨씬 간편해졌습니다. 새로운 제어 API를 통해 팀에서는 REST API 호출만으로 업데이트를 적용할 수 있으며, 재로드 성공 여부를 확인하기 위해 오류 로그를 모니터링할 필요가 없습니다. 결과적으로 구성 관리가 간소화되고, 통합이 더욱 깔끔해지며, CI/CD 파이프라인 자동화가 더욱 쉬워졌습니다.
JSON Error log with Custom Variables
이제 오류 로그를 더욱 쉽게 통합, 분석 및 조치할 수 있습니다. 오류 로그를 JSON 형식으로 내보내면 팀은 정규 표현식을 많이 사용하는 구문 분석이나 사용자 지정 스크립트 작성 필요성을 줄이고 로깅 파이프라인과의 연결을 간소화할 수 있습니다. 새로운 사용자 지정 옵션을 통해 개별 오류와 액세스 로그 항목 간의 상관 관계를 파악하는 등 더욱 풍부한 디버깅 워크플로를 구현할 수 있습니다.
Enhanced Upstream Latency Metrics
상위 시스템의 동작을 이해하는 것은 빠르고 안정적인 애플리케이션을 제공하는 데 필수적입니다. 지연 시간 히스토그램을 통해 팀은 이제 사용자 경험 문제, API 성능 문제 및 상위 시스템의 병목 현상을 그 어느 때보다 빠르게 파악할 수 있습니다.
업스트림 연결을 위한 HTTP/ 2 지원
애플리케이션은 업스트림 측에서 HTTP/2를 통해 NGINX와 통신할 수 있습니다. 이를 통해 개발팀은 백엔드 서비스가 기존 HTTP 프로토콜에 의존하지 않고도 최신 애플리케이션 아키텍처를 지원할 수 있는 유연성을 확보할 수 있습니다.
HTTP CONNECT 포워드 프록시 용 기본 인증
NGINX Plus R36에서 도입된 포워드 프록시 지원을 기반으로 하는 37.0 버전은 새로운 기본 인증 지원과 JWT 기반 인증을 위한 간소화된 설정 환경을 통해 클라이언트 인증 구현을 더욱 쉽게 만듭니다.
NGINX Open Sour ce에 관한 추가연구및 업데이트:
- 암호화 된 클라이언트 안녕하세요
- 멀티패스 TCP
- ACME 모듈 : 갱신 정보 지원
- 업스트림 연결은 이제 keepalive 기능이 활성화된 HTTP/1.1을 기본값으로 사용합니다 .
새로운 업적 상세
에이전트 관찰 가능성 : 실시간 MCP 트래픽 모니터링
에이전트 기반 워크로드는 새로운 유형의 트래픽 패턴을 도입합니다. 이는 여러 MCP 서버에 걸쳐 확산되고 시간이 지남에 따라 동작이 변할 수 있는 매우 동적이고 비결정적인 도구 호출입니다. 새로운 에이전트 관찰 가능성 모듈을 사용하면 NGINX는 MCP 트래픽을 실시간으로 검사하고 처리량, 지연 시간, 오류 및 추적 정보를 보고하여 어떤 에이전트가 트래픽을 생성하는지, 어떤 MCP 도구 및 서버가 병목 현상을 일으키는지, 그리고 장애가 어디에서 발생하는지 신속하게 파악할 수 있습니다.
AI 에이전트 및 MCP 서버 활동의 Grafana 대시보드
Agentic Observability를 시작하려면 NGINX Plus를 구성하여 nginx-mcp-js GitHub 저장소 의 mcp.js 모듈 , NGINX JavaScript 모듈 , nginx-otel 모듈 및 OpenTelemetry 백엔드를 사용하도록 설정하십시오. 설정 지침 및 샘플 구성 은 저장소 를 참조 하십시오 . 저장소 에는 Docker Compose , OpenTelemetry , Prometheus 및 Grafana 로 구축 된 배포 하기 쉬운 데모 환경 도 포함 되어 있습니다 .
NGINX Control API
NGINX Plus 37.0에서는 런타임 제어 및 내부 검사에 대한 프로그래밍 방식 접근을 제공하는 새로운 네이티브 제어 API가 도입되었습니다 . 이 API를 통해 워커 프로세스의 상태를 표시하고, 현재 메모리에 있는 구성 파일을 식별하고, NGINX 구성을 업데이트할 수 있습니다.
기존에는 NGINX 구성 업데이트가 UNIX 시그널 이나 `nginx -s reload` 명령줄 매개변수를 통해 시작되었습니다 . 이 방법은 구성의 구문 오류는 감지하지만, 재로드 성공 여부를 확인하려면 여전히 오류 로그 검사가 필요합니다. 예를 들어, 수신 소켓을 권한 있는 포트에 바인딩하는 경우 구성 구문 검사는 통과하지만, NGINX가 루트 권한으로 실행되지 않으면 결국 실패합니다. 새로운 제어 API는 구성 재로드 API 호출에 대한 응답으로 다운스트림 오류를 포함한 재로드 상태를 실시간으로 제공합니다.
Control API 활성화
제어 API를 활성화할 때는 주의해야 합니다. 외부 소켓을 통해 API 요청을 수신하도록 구성할 수 있지만, 이러한 구성은 강력히 권장하지 않습니다.
중요: 보안상의 이유로 API를 공개 포트, 공용 인터넷, 또는 어떤 광범위한 네트워크에 노출하지 마십시오.
NGINX를 실행할 때 -l 명령줄 인수 를 사용하여 제어 리스너를 활성화하십시오 . 예를 들어, Unix 소켓 /tmp/nginx.sock 에서 API를 노출하려면 다음 명령을 실행하십시오.
nginx -l unix:/tmp/nginx.sock
현재로서는 제어 API가 유닉스 소켓을 통해 수신 대기하도록 구성하는 것이 요청 권한 제어에 가장 적합한 방법입니다. 파일 권한을 통해 접근 권한을 관리할 수 있기 때문입니다. 생성된 유닉스 소켓 파일은 NGINX를 실행하는 사용자만 접근할 수 있습니다.
API 접근
API는 버전 관리되며 /1 URI를 통해 접근할 수 있습니다. 모든 HTTP 클라이언트를 사용하여 API에 접근할 수 있습니다. 다음 예제에서는 curl을 사용합니다. Unix 소켓을 통해 접근하는 API에 접근하려면 다음 명령어를 실행하십시오.
curl --unix-socket /tmp/nginx.sock http://localhost/1/
답변:
[ "control", "nginx" ]
실행 구성 검사
다음 명령은 현재 메모리에 로드된 구성을 반환합니다. 이는 NGINX가 현재 사용 중인 구성과 디스크에 저장된 구성 간의 차이점을 파악하는 데 유용합니다. 차이점이 발견되면 디스크의 구성이 변경되었지만 메모리에 성공적으로 로드되지 않았을 가능성이 있습니다.
curl --unix-socket /tmp/nginx.sock http://localhost/1/control/config
샘플 답변:
[
{
"name": "nginx.conf",
"content": " (...) "
},
{
"name": "stub.conf",
"content": " (...) "
}
]
구조화된 피드백 을 이용한 리로드 트리거링
다음 명령어를 실행하면 NGINX가 디스크에서 메모리로 설정을 불러옵니다. 이는 `nginx -s reload` 명령어를 실행하는 것과 동일 하지만, API를 통해 설정 구문 오류 외에도 다른 오류를 반환할 수 있다는 장점이 있습니다.
curl --unix-socket /tmp/nginx.sock -X PATCH http://localhost/1/control/config
샘플 답변:
{ "logs": [ “ .... “, “ .... “ ] }
JSON 형식 오류 로그
NGINX 오류 로그는 항상 귀중한 운영 통찰력을 제공해 왔지만, 기존의 문자열 기반 형식 때문에 대규모 환경에서 파싱하기가 어려웠습니다. 구조화된 필드나 일관된 구분 기호가 없었기 때문에, 팀들은 필요한 데이터를 추출하기 위해 정규 표현식, 사용자 지정 스크립트 또는 복잡한 휴리스틱에 의존해야 하는 경우가 많았습니다.
JSON은 구조화된 데이터를 표현하기 위해 현대 인프라 전반에서 널리 사용되며, 로깅, 모니터링 및 자동화 도구에서 JSON 파싱을 거의 보편적으로 지원합니다. NGINX Plus에서 JSON 형식의 오류 로그를 사용하면 운영자와 시스템 통합자는 사용자 지정 파서를 사용할 필요 없이 NGINX를 CI/CD 파이프라인, 로그 수집기 및 애플리케이션 모니터링 플랫폼에 더욱 쉽게 연결할 수 있습니다.
오류 로그 에서 JSON 형식 을 사용하려면 error_log 디렉터리 에 json 매개 변수 를 추가하여 수정 하십시오 .
error_log /var/log/nginx/error.json error json;
다음은 JSON 형식으로 된 오류 로그 항목의 예시입니다:
{
"level": "error",
"timestamp": "2026-05-04T10:30:15.042+00:00",
"pid": 12345, "tid": 12345, "cnum": 3,
"msg": "connect() failed",
"client": "192.168.1.10", "server": "example.com",
"request": "GET /api HTTP/1.1",
"upstream": "http://127.0.0.1:8080/api",
"errno": 111,
"errtext": "Connection refused"
}
사용자 정의 오류 로그 변수
NGINX Plus 액세스 로그는 일반적으로 트래픽을 검사하고 인프라 통합 문제를 해결하는 데 사용되지만, 액세스 로그 항목과 관련 오류 로그 이벤트를 연관시키는 것은 과거에는 어려웠습니다. 많은 경우, 팀은 타임스탬프 비교에 의존해야 했는데, 이는 동시 요청이 많은 대용량 시스템에서는 점점 더 신뢰성이 떨어졌습니다.
NGINX Plus 는 이제 사용자 지정 오류 로그 변수 를 통해 상관 관계 분석을 더욱 쉽게 수행 할 수 있도록 지원 합니다 . 새로운 `error_log_tag` 지시문을 사용하면 운영자 는 요청 식별자 , 호스트 정보, 정적 문자열, 수신 헤더에서 파생된 값 등 사용자 지정 컨텍스트를 오류 로그 항목에 추가할 수 있습니다. 이를 통해 오류를 발생시킨 요청, 클라이언트, 테넌트, 서비스 또는 워크플로와 더욱 쉽게 연결할 수 있습니다. 또한 NGINX Plus는 액세스 로그에서 타임스탬프 기반 상관 관계 분석을 오류 로그와 더욱 효과적으로 연동할 수 있도록 `$time_iso8601_ms` 변수 를 추가했습니다.
` error_log_tag` 지시문 은 텍스트 기반 NGINX 변수와 복잡한 표현식 을 허용 하며, JSON 형식 과 텍스트 형식의 오류 로그 항목 으로 사용자 지정 데이터 를 출력합니다. 다음 예에서 이 지시문은 각 오류 로그 항목에 상관 관계 식별자를 추가 합니다 .
server {
error_log_tag request_id $request_id;
error_log_tag x_request_id $http_x_request_id;
location /api/ {
proxy_pass http://backend;
}
}
향상된 업스트림 지연 시간 측정
낮은 지연 시간의 애플리케이션 전송은 빠르고 안정적인 사용자 경험을 제공하는 데 매우 중요합니다. 이전 NGINX Plus는 TCP 핸드셰이크, TLS 핸드셰이크, 요청 전송 및 응답 읽기를 포함한 전체 요청 수명 주기에 걸쳐 이동 평균으로 피어별 업스트림 지연 시간을 밀리초 단위로 보고했습니다. 평균값은 유용하지만, 지연 시간 급증, 장기적인 추세 또는 일부 요청에만 영향을 미치는 패턴과 같은 중요한 세부 정보를 가릴 수 있습니다.
NGINX Plus 37.0부터는 팀에서 각 업스트림 피어의 지연 시간 히스토그램을 확인할 수 있습니다 . 이를 통해 업스트림 성능을 더욱 자세히 파악하고, 지연 시간 분포를 이해하고, 백분위수를 분석하고, 이상치를 식별하고, 업스트림 동작을 다른 NGINX Plus 지표 및 인사이트와 연관 짓는 것이 더 쉬워집니다.
지연 시간 히스토그램 데이터는 NGINX Plus API를 통해 사용할 수 있으며, Prometheus-njs 익스포터 모듈을 사용하여 외부 관찰 시스템으로 내보낼 수 있고 , 아래 그림 과 같이 NGINX Plus 대시보드에서 직접 확인하여 한눈에 빠르게 정보를 파악할 수 있습니다.
NGINX Plus dashboar업데이트 후 새로운 업스트림 지연 데이터가 표시됩니다
보다 심층적인 진단을 위해 팀은 지연 시간 히스토그램 데이터를 Prometheus로 내보내고 Grafana에서 시각화할 수 있습니다. 아래 예시는 지연 시간 구간별 요청 밀도와 함께 p50, p95, p99 응답 시간, 요청 처리량, 업스트림 오류를 보여줍니다. 지연 시간 분포를 처리량 및 오류율과 비교함으로써 운영자는 성능 문제가 트래픽 급증, 업스트림 동작 또는 HTTP 오류로 인한 것인지 더 빠르게 파악할 수 있습니다.
업스트림 지연 시간 히스토그램을 통해 활성화된 새로운 기능을 보여주는 Grafana 대시보드 예시
다음 구성 예시는 업스트림 지연 시간 히스토그램을 활성화하는 방법을 보여줍니다. 히스토그램 데이터를 수집하려면 업스트림 블록에 공유 메모리 영역을 정의하십시오. 이렇게 하면 새로운 response_time_hist 필드를 포함하여 NGINX Plus에서 업스트림 수준의 원격 측정 기능을 사용할 수 있습니다.
http {
upstream my_backend {
zone my_backend 64k;
server backend1.example.com:8080;
server backend2.example.com:8080;
}
server {
listen 443 ssl;
location / {
proxy_pass http://my_backend;
}
# Expose the Nginx Plus API for metrics retrieval
location /api/ {
api write=on;
allow 127.0.0.1; # restrict to localhost only
deny all;
}
}
}
NGINX Plus API를 통해 업스트림 지연 시간 히스토그램에 액세스하려면 curl을 사용하여 다음 REST 호출을 실행하고 응답을 jq 로 파이프하여 형식을 쉽게 지정하세요.
curl -s http://localhost/api/9/http/upstreams/my_backend | jq
업스트림 연결을 위한 HTTP/ 2 지원
이전에는 NGINX Plus가 HTTP/1.0 또는 HTTP/1.1을 사용하여 업스트림 HTTP 연결을 지원했습니다. HTTP/1.1은 연결 유지와 같은 중요한 성능 이점을 제공했지만, 업스트림 애플리케이션은 여전히 기존 HTTP 프로토콜을 사용하여 NGINX와 통신해야 했습니다.
NGINX Plus 37.0은 HTTP/2 트래픽을 업스트림 서버로 직접 프록싱하고 로드 밸런싱하는 기능을 지원하여 팀에서 애플리케이션 전달 경로에 HTTP/2를 더욱 깊숙이 확장할 수 있도록 합니다.
업스트림에 대한 HTTP/2 연결을 활성화하려면 다음 예제 구성을 사용하십시오.
upstream http_backend {
server 127.0.0.1:8080;
keepalive 16;
}
server {
...
location /http/ {
proxy_pass http://http_backend;
proxy_http_version 2
proxy_set_header Connection "";
...
}
} 참고: 현재 업스트림에 대한 HTTP/2 연결 구현은 요청 다중화를 지원하지 않습니다.
HTTP CONNECT 포워드 프록시 용 기본 인증
NGINX Plus R36에서는 HTTP CONNECT 프로토콜을 사용하여 NGINX Plus를 포워드 프록시로 구성하는 기능을 지원했습니다. 37.0 버전에서는 이 기능을 기반으로 HTTP CONNECT 요청에 대한 기본 인증 지원을 추가했습니다. 이를 통해 팀은 NGINX Plus를 통해 프록시 터널을 설정하기 전에 클라이언트를 인증하는 또 다른 간편한 옵션을 사용할 수 있습니다.
HTTP CONNECT 포워드 프록시에 기본 인증을 활성화하려면 다음 예제 구성을 사용하십시오.
server {
listen 3128;
auth_basic "my proxy";
auth_basic_user_file conf/htpasswd;
tunnel_pass;
}
장기 지원 ( LTS )
NGINX Plus 37.0부터 일부 릴리스는 장기 지원(LTS) 릴리스로 인증됩니다. 자세한 내용은 LTS 프로그램 및 LTS와 비LTS 릴리스 전반에 걸친 지원 정책에 대한 내용을 참조하십시오.
LTS 릴리스 도입으로 NGINX Plus의 설치, 버전 관리 및 업데이트 방식이 변경되었습니다. 고객께서는 NGINX Plus 설치 가이드를 주의 깊게 읽고 업데이트된 버전 관리 체계를 숙지하시기 바랍니다. 향후 LTS가 아닌 릴리스는 더 이상 NGINX Plus의 주요 릴리스 번호를 증가시키지 않습니다. 예를 들어, 37.0 이후의 LTS가 아닌 릴리스는 37.1로, 다음 LTS 릴리스는 R38.0으로 버전이 지정됩니다. 모듈 및 패키지 버전도 동일한 체계를 따릅니다. 예를 들어, NGINX Plus R36은 nginx-plus 36-1~noble과 같은 패키지 버전을 사용했지만, 37.0부터는 nginx-plus 37.0.0-1~noble과 같이 패키지 버전 형식이 변경됩니다.
NGINX Plus 패키지 저장소 경로도 변경됩니다. 저장소를 37.0 릴리스로 고정하려면 이전의 /plus/R36/... 형식 대신 저장소 URI에 /plus/R37.0/...을 사용하십시오.
경우에 따라 릴리스는 전체 버전 이름으로 참조될 수 있습니다. 예를 들어, 37.0 릴리스의 공식 명칭은 PLS.37.0.0.1이며, 마지막 숫자는 최초 패키지 릴리스를 나타냅니다. 버전 번호의 의미에 대한 자세한 내용은 LTS 프로그램 블로그 게시물을 참조하십시오 .
중요: LTS 업그레이드 경로를 유지하려면 /plus/LTS URI에 고정하는 것이 좋습니다. 이렇게 하면 향후 업그레이드 시에도 LTS 릴리스를 유지하고 의도치 않게 배포 환경이 비LTS 릴리스로 이동하는 것을 방지할 수 있습니다.
NGINX Plus 37.0에서 제공되는 추가 향상
NGINX Plus 37.0은 NGINX 1.29.8 메인라인 릴리스 를 기반으로 하며 , NGINX Plus R36( 1.29.3 메인 라인 릴리스 기반 ) 출시 이후 이루어진 모든 기능 변경 사항, 특징 및 버그 수정 사항을 계승합니다. 최근 릴리스에서 계승된 새로운 변경 사항, 특징, 버그 수정 사항 및 해결 방법의 전체 목록은 NGINX 변경 로그를 참조하십시오 .
플랫폼 지원 변경 사항
Platforms 추가됨
다음 플랫폼에 대한 지원이 추가되었습니다:
- Alpine Linux 3.23
- FreeBSD 15
- Ubuntu 26.04
참고: Ubuntu 26.04부터 구형 amd64 하드웨어 변형에 대한 지원 이 종료 됩니다 . 자세한 내용 은 다음 링크 를 참조 하세요 . https://documentation.ubuntu.com/project/how-ubuntu-is-made/concepts/supported-architectures/#architecture-variants
NGINX Plus는 amd64v3에서 지원됩니다. 구형 하드웨어 변형에서의 지원은 이전 버전의 Ubuntu LTS 릴리스(예: Ubuntu 24.04 LTS)를 실행하여 구현할 수 있습니다.
Removed Platforms
다음 플랫폼에 대한 지원이 제거되었습니다:
- Alpine Linux 3.20 – 2026년 4월 1일 SuppoRt 종료
Deprecated Platforms
다음 플랫폼에 대한 지원은 향후 버전에서 제거될 예정입니다:
- 알파인 리눅 스 3.21
- 아마존 리눅스 2
- FreeBSD 13
F5 NGINX Plus 37.0 출시
F5 NGINX Plus 37.0 버전 출시를 발표하게 되어 매우 기쁩니다. 이번 릴리스에는 에이전트 트래픽 모니터링, 새로운 API를 통한 원격 구성 제어, 사용자 지정 변수를 포함한 JSON 형식의 오류 로그, 고정밀 메트릭을 사용한 업스트림 지연 시간 모니터링 등 매우 광범위한 새로운 기능이 포함되어 있습니다.
또한, 제품 수명 주기 계획을 지원하기 위해 NGINX Plus 37.0은 새로운 장기 지원(LTS) 정책에 따라 지원되는 첫 번째 릴리스가 될 것입니다. 왜 R37이 아닌 37.0 릴리스인지 궁금하시죠? LTS 정책 도입으로 NGINX Plus의 버전 관리 방식이 변경되었기 때문입니다 .
NGINX Plus는 언제나처럼 검증되고 신뢰할 수 있는 올인원 소프트웨어 웹 서버, 로드 밸런싱, 리버스 프록시, 콘텐츠 캐시 및 API 게이트웨이인 NGINX 오픈 소스의 최신 기능을 모두 계승합니다. NGINX 오픈 소스 와 NGINX Plus의 최신 기능, 버그 수정 및 보안 패치를 모두 활용하려면 최신 NGINX Plus 릴리스로 업그레이드하는 것을 적극 권장합니다 .
다음은 37.0에서 가장 중요한 업데이트 요약입니다:
에이전트 관찰 가능성 : 실시간 MCP 트래픽 모니터링
NGINX Plus는 새로운 관찰 기능을 통해 에이전트 기반 AI 시대를 맞이할 준비가 되어 있습니다. 이 기능을 통해 팀은 AI 에이전트 활동을 추적 및 모니터링하고, 과도하게 통신하는 에이전트를 식별하고, 오류 발생 가능성이 높은 MCP 도구를 파악하고, MCP 서버 지연 시간을 감지하고, 새롭게 나타나는 AI 애플리케이션 패턴에 대한 문제 해결을 지원할 수 있습니다.
Control API
NGINX Plus 재구성 작업이 훨씬 간편해졌습니다. 새로운 제어 API를 통해 팀에서는 REST API 호출만으로 업데이트를 적용할 수 있으며, 재로드 성공 여부를 확인하기 위해 오류 로그를 모니터링할 필요가 없습니다. 결과적으로 구성 관리가 간소화되고, 통합이 더욱 깔끔해지며, CI/CD 파이프라인 자동화가 더욱 쉬워졌습니다.
JSON Error log with Custom Variables
이제 오류 로그를 더욱 쉽게 통합, 분석 및 조치할 수 있습니다. 오류 로그를 JSON 형식으로 내보내면 팀은 정규 표현식을 많이 사용하는 구문 분석이나 사용자 지정 스크립트 작성 필요성을 줄이고 로깅 파이프라인과의 연결을 간소화할 수 있습니다. 새로운 사용자 지정 옵션을 통해 개별 오류와 액세스 로그 항목 간의 상관 관계를 파악하는 등 더욱 풍부한 디버깅 워크플로를 구현할 수 있습니다.
Enhanced Upstream Latency Metrics
상위 시스템의 동작을 이해하는 것은 빠르고 안정적인 애플리케이션을 제공하는 데 필수적입니다. 지연 시간 히스토그램을 통해 팀은 이제 사용자 경험 문제, API 성능 문제 및 상위 시스템의 병목 현상을 그 어느 때보다 빠르게 파악할 수 있습니다.
업스트림 연결을 위한 HTTP/ 2 지원
애플리케이션은 업스트림 측에서 HTTP/2를 통해 NGINX와 통신할 수 있습니다. 이를 통해 개발팀은 백엔드 서비스가 기존 HTTP 프로토콜에 의존하지 않고도 최신 애플리케이션 아키텍처를 지원할 수 있는 유연성을 확보할 수 있습니다.
HTTP CONNECT 포워드 프록시 용 기본 인증
NGINX Plus R36에서 도입된 포워드 프록시 지원을 기반으로 하는 37.0 버전은 새로운 기본 인증 지원과 JWT 기반 인증을 위한 간소화된 설정 환경을 통해 클라이언트 인증 구현을 더욱 쉽게 만듭니다.
NGINX Open Sour ce에 관한 추가연구및 업데이트:
새로운 업적 상세
에이전트 관찰 가능성 : 실시간 MCP 트래픽 모니터링
에이전트 기반 워크로드는 새로운 유형의 트래픽 패턴을 도입합니다. 이는 여러 MCP 서버에 걸쳐 확산되고 시간이 지남에 따라 동작이 변할 수 있는 매우 동적이고 비결정적인 도구 호출입니다. 새로운 에이전트 관찰 가능성 모듈을 사용하면 NGINX는 MCP 트래픽을 실시간으로 검사하고 처리량, 지연 시간, 오류 및 추적 정보를 보고하여 어떤 에이전트가 트래픽을 생성하는지, 어떤 MCP 도구 및 서버가 병목 현상을 일으키는지, 그리고 장애가 어디에서 발생하는지 신속하게 파악할 수 있습니다.
AI 에이전트 및 MCP 서버 활동의 Grafana 대시보드
Agentic Observability를 시작하려면 NGINX Plus를 구성하여 nginx-mcp-js GitHub 저장소 의 mcp.js 모듈 , NGINX JavaScript 모듈 , nginx-otel 모듈 및 OpenTelemetry 백엔드를 사용하도록 설정하십시오. 설정 지침 및 샘플 구성 은 저장소 를 참조 하십시오 . 저장소 에는 Docker Compose , OpenTelemetry , Prometheus 및 Grafana 로 구축 된 배포 하기 쉬운 데모 환경 도 포함 되어 있습니다 .
NGINX Control API
NGINX Plus 37.0에서는 런타임 제어 및 내부 검사에 대한 프로그래밍 방식 접근을 제공하는 새로운 네이티브 제어 API가 도입되었습니다 . 이 API를 통해 워커 프로세스의 상태를 표시하고, 현재 메모리에 있는 구성 파일을 식별하고, NGINX 구성을 업데이트할 수 있습니다.
기존에는 NGINX 구성 업데이트가 UNIX 시그널 이나 `nginx -s reload` 명령줄 매개변수를 통해 시작되었습니다 . 이 방법은 구성의 구문 오류는 감지하지만, 재로드 성공 여부를 확인하려면 여전히 오류 로그 검사가 필요합니다. 예를 들어, 수신 소켓을 권한 있는 포트에 바인딩하는 경우 구성 구문 검사는 통과하지만, NGINX가 루트 권한으로 실행되지 않으면 결국 실패합니다. 새로운 제어 API는 구성 재로드 API 호출에 대한 응답으로 다운스트림 오류를 포함한 재로드 상태를 실시간으로 제공합니다.
Control API 활성화
제어 API를 활성화할 때는 주의해야 합니다. 외부 소켓을 통해 API 요청을 수신하도록 구성할 수 있지만, 이러한 구성은 강력히 권장하지 않습니다.
중요: 보안상의 이유로 API를 공개 포트, 공용 인터넷, 또는 어떤 광범위한 네트워크에 노출하지 마십시오.
NGINX를 실행할 때 -l 명령줄 인수 를 사용하여 제어 리스너를 활성화하십시오 . 예를 들어, Unix 소켓 /tmp/nginx.sock 에서 API를 노출하려면 다음 명령을 실행하십시오.
현재로서는 제어 API가 유닉스 소켓을 통해 수신 대기하도록 구성하는 것이 요청 권한 제어에 가장 적합한 방법입니다. 파일 권한을 통해 접근 권한을 관리할 수 있기 때문입니다. 생성된 유닉스 소켓 파일은 NGINX를 실행하는 사용자만 접근할 수 있습니다.
API 접근
API는 버전 관리되며 /1 URI를 통해 접근할 수 있습니다. 모든 HTTP 클라이언트를 사용하여 API에 접근할 수 있습니다. 다음 예제에서는 curl을 사용합니다. Unix 소켓을 통해 접근하는 API에 접근하려면 다음 명령어를 실행하십시오.
답변:
실행 구성 검사
다음 명령은 현재 메모리에 로드된 구성을 반환합니다. 이는 NGINX가 현재 사용 중인 구성과 디스크에 저장된 구성 간의 차이점을 파악하는 데 유용합니다. 차이점이 발견되면 디스크의 구성이 변경되었지만 메모리에 성공적으로 로드되지 않았을 가능성이 있습니다.
샘플 답변:
[ { "name": "nginx.conf", "content": " (...) " }, { "name": "stub.conf", "content": " (...) " } ]구조화된 피드백 을 이용한 리로드 트리거링
다음 명령어를 실행하면 NGINX가 디스크에서 메모리로 설정을 불러옵니다. 이는 `nginx -s reload` 명령어를 실행하는 것과 동일 하지만, API를 통해 설정 구문 오류 외에도 다른 오류를 반환할 수 있다는 장점이 있습니다.
샘플 답변:
{ "logs": [ “ .... “, “ .... “ ] }JSON 형식 오류 로그
NGINX 오류 로그는 항상 귀중한 운영 통찰력을 제공해 왔지만, 기존의 문자열 기반 형식 때문에 대규모 환경에서 파싱하기가 어려웠습니다. 구조화된 필드나 일관된 구분 기호가 없었기 때문에, 팀들은 필요한 데이터를 추출하기 위해 정규 표현식, 사용자 지정 스크립트 또는 복잡한 휴리스틱에 의존해야 하는 경우가 많았습니다.
JSON은 구조화된 데이터를 표현하기 위해 현대 인프라 전반에서 널리 사용되며, 로깅, 모니터링 및 자동화 도구에서 JSON 파싱을 거의 보편적으로 지원합니다. NGINX Plus에서 JSON 형식의 오류 로그를 사용하면 운영자와 시스템 통합자는 사용자 지정 파서를 사용할 필요 없이 NGINX를 CI/CD 파이프라인, 로그 수집기 및 애플리케이션 모니터링 플랫폼에 더욱 쉽게 연결할 수 있습니다.
오류 로그 에서 JSON 형식 을 사용하려면 error_log 디렉터리 에 json 매개 변수 를 추가하여 수정 하십시오 .
다음은 JSON 형식으로 된 오류 로그 항목의 예시입니다:
{ "level": "error", "timestamp": "2026-05-04T10:30:15.042+00:00", "pid": 12345, "tid": 12345, "cnum": 3, "msg": "connect() failed", "client": "192.168.1.10", "server": "example.com", "request": "GET /api HTTP/1.1", "upstream": "http://127.0.0.1:8080/api", "errno": 111, "errtext": "Connection refused" }사용자 정의 오류 로그 변수
NGINX Plus 액세스 로그는 일반적으로 트래픽을 검사하고 인프라 통합 문제를 해결하는 데 사용되지만, 액세스 로그 항목과 관련 오류 로그 이벤트를 연관시키는 것은 과거에는 어려웠습니다. 많은 경우, 팀은 타임스탬프 비교에 의존해야 했는데, 이는 동시 요청이 많은 대용량 시스템에서는 점점 더 신뢰성이 떨어졌습니다.
NGINX Plus 는 이제 사용자 지정 오류 로그 변수 를 통해 상관 관계 분석을 더욱 쉽게 수행 할 수 있도록 지원 합니다 . 새로운 `error_log_tag` 지시문을 사용하면 운영자 는 요청 식별자 , 호스트 정보, 정적 문자열, 수신 헤더에서 파생된 값 등 사용자 지정 컨텍스트를 오류 로그 항목에 추가할 수 있습니다. 이를 통해 오류를 발생시킨 요청, 클라이언트, 테넌트, 서비스 또는 워크플로와 더욱 쉽게 연결할 수 있습니다. 또한 NGINX Plus는 액세스 로그에서 타임스탬프 기반 상관 관계 분석을 오류 로그와 더욱 효과적으로 연동할 수 있도록 `$time_iso8601_ms` 변수 를 추가했습니다.
` error_log_tag` 지시문 은 텍스트 기반 NGINX 변수와 복잡한 표현식 을 허용 하며, JSON 형식 과 텍스트 형식의 오류 로그 항목 으로 사용자 지정 데이터 를 출력합니다. 다음 예에서 이 지시문은 각 오류 로그 항목에 상관 관계 식별자를 추가 합니다 .
server { error_log_tag request_id $request_id; error_log_tag x_request_id $http_x_request_id; location /api/ { proxy_pass http://backend; } }향상된 업스트림 지연 시간 측정
낮은 지연 시간의 애플리케이션 전송은 빠르고 안정적인 사용자 경험을 제공하는 데 매우 중요합니다. 이전 NGINX Plus는 TCP 핸드셰이크, TLS 핸드셰이크, 요청 전송 및 응답 읽기를 포함한 전체 요청 수명 주기에 걸쳐 이동 평균으로 피어별 업스트림 지연 시간을 밀리초 단위로 보고했습니다. 평균값은 유용하지만, 지연 시간 급증, 장기적인 추세 또는 일부 요청에만 영향을 미치는 패턴과 같은 중요한 세부 정보를 가릴 수 있습니다.
NGINX Plus 37.0부터는 팀에서 각 업스트림 피어의 지연 시간 히스토그램을 확인할 수 있습니다 . 이를 통해 업스트림 성능을 더욱 자세히 파악하고, 지연 시간 분포를 이해하고, 백분위수를 분석하고, 이상치를 식별하고, 업스트림 동작을 다른 NGINX Plus 지표 및 인사이트와 연관 짓는 것이 더 쉬워집니다.
지연 시간 히스토그램 데이터는 NGINX Plus API를 통해 사용할 수 있으며, Prometheus-njs 익스포터 모듈을 사용하여 외부 관찰 시스템으로 내보낼 수 있고 , 아래 그림 과 같이 NGINX Plus 대시보드에서 직접 확인하여 한눈에 빠르게 정보를 파악할 수 있습니다.
NGINX Plus dashboar업데이트 후 새로운 업스트림 지연 데이터가 표시됩니다
보다 심층적인 진단을 위해 팀은 지연 시간 히스토그램 데이터를 Prometheus로 내보내고 Grafana에서 시각화할 수 있습니다. 아래 예시는 지연 시간 구간별 요청 밀도와 함께 p50, p95, p99 응답 시간, 요청 처리량, 업스트림 오류를 보여줍니다. 지연 시간 분포를 처리량 및 오류율과 비교함으로써 운영자는 성능 문제가 트래픽 급증, 업스트림 동작 또는 HTTP 오류로 인한 것인지 더 빠르게 파악할 수 있습니다.
업스트림 지연 시간 히스토그램을 통해 활성화된 새로운 기능을 보여주는 Grafana 대시보드 예시
다음 구성 예시는 업스트림 지연 시간 히스토그램을 활성화하는 방법을 보여줍니다. 히스토그램 데이터를 수집하려면 업스트림 블록에 공유 메모리 영역을 정의하십시오. 이렇게 하면 새로운 response_time_hist 필드를 포함하여 NGINX Plus에서 업스트림 수준의 원격 측정 기능을 사용할 수 있습니다.
http { upstream my_backend { zone my_backend 64k; server backend1.example.com:8080; server backend2.example.com:8080; } server { listen 443 ssl; location / { proxy_pass http://my_backend; } # Expose the Nginx Plus API for metrics retrieval location /api/ { api write=on; allow 127.0.0.1; # restrict to localhost only deny all; } } }NGINX Plus API를 통해 업스트림 지연 시간 히스토그램에 액세스하려면 curl을 사용하여 다음 REST 호출을 실행하고 응답을 jq 로 파이프하여 형식을 쉽게 지정하세요.
업스트림 연결을 위한 HTTP/ 2 지원
이전에는 NGINX Plus가 HTTP/1.0 또는 HTTP/1.1을 사용하여 업스트림 HTTP 연결을 지원했습니다. HTTP/1.1은 연결 유지와 같은 중요한 성능 이점을 제공했지만, 업스트림 애플리케이션은 여전히 기존 HTTP 프로토콜을 사용하여 NGINX와 통신해야 했습니다.
NGINX Plus 37.0은 HTTP/2 트래픽을 업스트림 서버로 직접 프록싱하고 로드 밸런싱하는 기능을 지원하여 팀에서 애플리케이션 전달 경로에 HTTP/2를 더욱 깊숙이 확장할 수 있도록 합니다.
업스트림에 대한 HTTP/2 연결을 활성화하려면 다음 예제 구성을 사용하십시오.
upstream http_backend { server 127.0.0.1:8080; keepalive 16; } server { ... location /http/ { proxy_pass http://http_backend; proxy_http_version 2 proxy_set_header Connection ""; ... } }참고: 현재 업스트림에 대한 HTTP/2 연결 구현은 요청 다중화를 지원하지 않습니다.
HTTP CONNECT 포워드 프록시 용 기본 인증
NGINX Plus R36에서는 HTTP CONNECT 프로토콜을 사용하여 NGINX Plus를 포워드 프록시로 구성하는 기능을 지원했습니다. 37.0 버전에서는 이 기능을 기반으로 HTTP CONNECT 요청에 대한 기본 인증 지원을 추가했습니다. 이를 통해 팀은 NGINX Plus를 통해 프록시 터널을 설정하기 전에 클라이언트를 인증하는 또 다른 간편한 옵션을 사용할 수 있습니다.
HTTP CONNECT 포워드 프록시에 기본 인증을 활성화하려면 다음 예제 구성을 사용하십시오.
server { listen 3128; auth_basic "my proxy"; auth_basic_user_file conf/htpasswd; tunnel_pass; }장기 지원 ( LTS )
NGINX Plus 37.0부터 일부 릴리스는 장기 지원(LTS) 릴리스로 인증됩니다. 자세한 내용은 LTS 프로그램 및 LTS와 비LTS 릴리스 전반에 걸친 지원 정책에 대한 내용을 참조하십시오.
LTS 릴리스 도입으로 NGINX Plus의 설치, 버전 관리 및 업데이트 방식이 변경되었습니다. 고객께서는 NGINX Plus 설치 가이드를 주의 깊게 읽고 업데이트된 버전 관리 체계를 숙지하시기 바랍니다. 향후 LTS가 아닌 릴리스는 더 이상 NGINX Plus의 주요 릴리스 번호를 증가시키지 않습니다. 예를 들어, 37.0 이후의 LTS가 아닌 릴리스는 37.1로, 다음 LTS 릴리스는 R38.0으로 버전이 지정됩니다. 모듈 및 패키지 버전도 동일한 체계를 따릅니다. 예를 들어, NGINX Plus R36은 nginx-plus 36-1~noble과 같은 패키지 버전을 사용했지만, 37.0부터는 nginx-plus 37.0.0-1~noble과 같이 패키지 버전 형식이 변경됩니다.
NGINX Plus 패키지 저장소 경로도 변경됩니다. 저장소를 37.0 릴리스로 고정하려면 이전의 /plus/R36/... 형식 대신 저장소 URI에 /plus/R37.0/...을 사용하십시오.
경우에 따라 릴리스는 전체 버전 이름으로 참조될 수 있습니다. 예를 들어, 37.0 릴리스의 공식 명칭은 PLS.37.0.0.1이며, 마지막 숫자는 최초 패키지 릴리스를 나타냅니다. 버전 번호의 의미에 대한 자세한 내용은 LTS 프로그램 블로그 게시물을 참조하십시오 .
중요: LTS 업그레이드 경로를 유지하려면 /plus/LTS URI에 고정하는 것이 좋습니다. 이렇게 하면 향후 업그레이드 시에도 LTS 릴리스를 유지하고 의도치 않게 배포 환경이 비LTS 릴리스로 이동하는 것을 방지할 수 있습니다.
NGINX Plus 37.0에서 제공되는 추가 향상
NGINX Plus 37.0은 NGINX 1.29.8 메인라인 릴리스 를 기반으로 하며 , NGINX Plus R36( 1.29.3 메인 라인 릴리스 기반 ) 출시 이후 이루어진 모든 기능 변경 사항, 특징 및 버그 수정 사항을 계승합니다. 최근 릴리스에서 계승된 새로운 변경 사항, 특징, 버그 수정 사항 및 해결 방법의 전체 목록은 NGINX 변경 로그를 참조하십시오 .
플랫폼 지원 변경 사항
Platforms 추가됨
다음 플랫폼에 대한 지원이 추가되었습니다:
참고: Ubuntu 26.04부터 구형 amd64 하드웨어 변형에 대한 지원 이 종료 됩니다 . 자세한 내용 은 다음 링크 를 참조 하세요 . https://documentation.ubuntu.com/project/how-ubuntu-is-made/concepts/supported-architectures/#architecture-variants
NGINX Plus는 amd64v3에서 지원됩니다. 구형 하드웨어 변형에서의 지원은 이전 버전의 Ubuntu LTS 릴리스(예: Ubuntu 24.04 LTS)를 실행하여 구현할 수 있습니다.
Removed Platforms
다음 플랫폼에 대한 지원이 제거되었습니다:
Deprecated Platforms
다음 플랫폼에 대한 지원은 향후 버전에서 제거될 예정입니다: