Question 1

'nginx -s stop' 명령이 설정 파일이 유효하지 않을 때 서버를 중지하지 못하는 이유는 무엇인가요?

Accepted Answer

nginx는 '-s stop' 명령에서도 설정을 검증하므로, 오류가 있으면 중지를 거부합니다. 해결 방법으로 systemctl stop nginx(systemd)를 사용하거나, nginx 마스터 프로세스에 직접 QUIT 신호를 보내십시오(예: kill -QUIT $(cat /var/run/nginx.pid)). 또한 설정 파일을 임시로 수정하여 깔끔하게 중지할 수 있습니다.

Question 2

location 블록 안의 nginx client_max_body_size가 적용되지 않는 이유는 무엇인가요? (413 에러)

Accepted Answer

nginx는 `index` 지시어가 `/members/`를 `/members/index.php`로 내부 리다이렉트하기 전에, *원래* 요청 URI와 일치하는 location을 기준으로 `client_max_body_size`를 검사합니다. 따라서 `/members/login/`에 대한 요청은 `location ~* ^/members/.*\.php$`와 절대 일치하지 않으며, 정규식 location이 평가되기도 전에 서버 수준 값(예: 3k)으로 폴백하여 413 Request Entity Too Large를 반환합니다. 해결 방법: 대신 접두사 location 안에 중첩된 정규식 location을 사용하세요:

```nginx
location /members/ {
    client_max_body_size 10m;
    location ~* \.php$ {
        fastcgi_param ...;
    }
}
```

접두사 location은 원래 URI `/members/...`와 일치하므로 10m 제한이 적용되고, 중첩된 정규식이 PHP 처리를 담당합니다.

Question 3

KTLS를 사용하는 HTTP/2에서 lingering_close 중 발생하는 nginx 'recv() failed (5: Input/output error)' 오류 해결 방법

Accepted Answer

이 alert는 무해합니다(연결이 정상적으로 종료되며 실패한 요청도 없음). 이는 OpenSSL 3.2.0+의 동작 변경으로 인해 발생하는데, OpenSSL 3.2.0+는 TLS 1.3에 대해 kTLS receive offload를 활성화합니다. lingering close 중에 nginx는 일반 `recv()`로 소켓을 drain하지만, kTLS offload가 활성화된 상태에서는 커널이 일반 `recv()`를 통해 클라이언트의 TLS `close_notify` 레코드를 반환할 수 없습니다. 따라서 해당 호출이 0 대신 -1 (EIO)을 반환하고, nginx는 이를 alert 레벨로 기록합니다.

해결 방법 (패치 불필요, 하나만 선택):

1. nginx 설정에서 lingering close 비활성화:
```
http {
    lingering_close off;
}
```

2. 또는 다음 지시어를 제거하여 KTLS 비활성화:
```
ssl_conf_command Options KTLS;
```

발생 조건: OpenSSL 3.2.0 이상으로 빌드된 nginx(OpenSSL 3.5.x/4.0.x 및 nginx 1.29–1.31에서도 여전히 존재함), KTLS 활성화, 그리고 `lingering_close on`(기본값). 이는 모든 HTTP/2 연결 종료 시 발생하며, 예를 들어 `nginx -s reload` 중이거나 `keepalive_requests`가 소진되었을 때 트리거됩니다. HTTP/1.1과 HTTP/2 lingering close 핸들러 모두 영향을 받습니다. nginx가 이 OpenSSL 변경 사항을 기본적으로 처리할 때까지, 위의 해결 방법 중 하나를 사용하여 로그 스팸을 제거하세요.

Question 4

왜 내 사용자 정의 NGINX stream module이 성공적인 SSL handshake 후에 멈추나요?

Accepted Answer

표준 `ngx_stream_ssl_init_connection()` 함수는 성공적인 핸드셰이크 후에 `NGX_OK`를 반환하며, 핸드셰이크 핸들러를 호출하지 않습니다. 왜냐하면 이 함수가 스트림 페이즈 엔진 루프(`ngx_stream_core_run_phases`) 내에서 호출되기 때문입니다. 페이즈 엔진은 `NGX_OK`가 반환되면 자동으로 다음 페이즈로 진행합니다. 사용자 정의 모듈이 이 페이즈 엔진 컨텍스트 외부에서 SSL 핸드셰이크를 시작하는 경우, 핸드셰이크가 중단되지 않도록 `ngx_stream_core_run_phases(s)`를 호출하거나 페이즈 로직을 복제해야 합니다.

Question 5

NGINX의 set 지시문 내에서 $slice_range를 사용할 때 proxy_cache_key가 정적인 이유는 무엇인가요?

Accepted Answer

`set` 지시문은 할당 시점에 복잡한 값을 평가하므로, 주 요청에 대해 `$cache_key`가 정적(static)이 됩니다. 슬라이스 모듈의 하위 요청(subrequest)에서는 `$slice_range`가 변경되지만, 캐시된 값은 이를 반영하지 않습니다. 해결 방법: `proxy_cache_key`에 `$slice_range`를 직접 사용합니다. 예: `proxy_cache_key "$uri:$slice_range";`. 느린 평가(lazy evaluation)를 위해 패치나 (`map`과 같은) `volatile` 매개변수가 필요할 수 있습니다.

nginx

주요 기능

할 수 없는 것

사용 사례

태그

시작하기

유사한 프로젝트