server {
listen 80;
server_name foo.com;
root /path;
location / {
index index.html index.htm index.php;
if (!-e $request_filename) {
rewrite . /index.php last;
}
}
location ~ \.php$ {
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME /path$fastcgi_script_name;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
}
}로그인 후 복사
1) 不应该在location 模块定义index
一旦未来需要加入新的「location」，必然会出现重复定义的「index」指令，这是因为多个「location」是平级的关系，不存在继承，此时应该在「server」里定义「index」，借助继承关系，「index」指令在所有的「location」中都能生效。
2) 使用try_files
接下来看看「if」指令，说它是大家误解最深的Nginx指令毫不为过：
if (!-e $request_filename) {
rewrite . /index.php last;
}
很多人喜欢用「if」指令做一系列的检查，不过这实际上是「try_files」指令的职责：
try_files $uri $uri/ /index.php;
除此以外，初学者往往会认为「if」指令是内核级的指令，但是实际上它是rewrite模块的一部分，加上Nginx配置实际上是声明式的，而非过程式的，所以当其和非rewrite模块的指令混用时，结果可能会非你所愿。
3）fastcgi_params」配置文件：
include fastcgi_params;
Nginx有两份fastcgi配置文件，分别是「fastcgi_params」和「fastcgi.conf」，它们没有太大的差异，唯一的区别是后者比前者多了一行「SCRIPT_FILENAME」的定义：
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
注意：$document_root 和 $fastcgi_script_name 之间没有 /。
原本Nginx只有「fastcgi_params」，后来发现很多人在定义「SCRIPT_FILENAME」时使用了硬编码的方式，于是为了规范用法便引入了「fastcgi.conf」。
不过这样的话就产生一个疑问：为什么一定要引入一个新的配置文件，而不是修改旧的配置文件？这是因为「fastcgi_param」指令是数组型的，和普通指令相同的是：内层替换外层；和普通指令不同的是：当在同级多次使用的时候，是新增而不是替换。换句话说，如果在同级定义两次「SCRIPT_FILENAME」，那么它们都会被发送到后端，这可能会导致一些潜在的问题，为了避免此类情况，便引入了一个新的配置文件。
此外，我们还需要考虑一个安全问题：在PHP开启「cgi.fix_pathinfo」的情况下，PHP可能会把错误的文件类型当作PHP文件来解析。如果Nginx和PHP安装在同一台服务器上的话，那么最简单的解决方法是用「try_files」指令做一次过滤：
try_files $uri =404;
依照前面的分析，给出一份改良后的版本，是不是比开始的版本清爽了很多：
server {
listen 80;
server_name foo.com;
root /path;
index index.html index.htm index.php;
location / {
try_files $uri $uri/ /index.php;
}
location ~ \.php$ {
try_files $uri =404;
include fastcgi.conf;
fastcgi_pass 127.0.0.1:9000;
}
}로그인 후 복사
六. Nginx优化
1. 编译安装过程优化
1）.减小Nginx编译后的文件大小
在编译Nginx时，默认以debug模式进行，而在debug模式下会插入很多跟踪和ASSERT之类的信息，编译完成后，一个Nginx要有好几兆字节。而在编译前取消Nginx的debug模式，编译完成后Nginx只有几百千字节。因此可以在编译之前，修改相关源码，取消debug模式。具体方法如下：
在Nginx源码文件被解压后，找到源码目录下的auto/cc/gcc文件，在其中找到如下几行：
# debug
CFLAGS=”$CFLAGS -g”
로그인 후 복사
注释掉或删掉这两行，即可取消debug模式。
2.为特定的CPU指定CPU类型编译优化
在编译Nginx时，默认的GCC编译参数是“-O”，要优化GCC编译，可以使用以下两个参数：
- --with-cc-opt='-O3'
- --with-cpu-opt=CPU # 특정 CPU에 대한 컴파일에는 유효한 값이 포함됩니다. :
pentium, pentiumpro, pentium3, # pentium4, athlon, opteron, amd64, sparc32, sparc64, ppc64
CPU 유형을 확인하려면 다음 명령을 사용할 수 있습니다: #cat /proc/cpuinfo | grep "model name"
2. TCMalloc을 사용하여 Nginx 성능 최적화
TCMalloc의 전체 이름은 Thread-Caching Malloc이며 Google에서 개발한 오픈 소스 도구 google-perftools의 구성원입니다. 표준 glibc 라이브러리의 Malloc과 비교하여 TCMalloc 라이브러리는 메모리 할당이 훨씬 더 효율적이고 빠릅니다. 이는 동시성이 높은 상황에서 서버 성능을 크게 향상시켜 시스템의 부하를 줄입니다. 다음은 Nginx에 TCMalloc 라이브러리 지원을 추가하는 방법에 대한 간략한 소개입니다.
TCMalloc 라이브러리를 설치하려면 libunwind(32비트 운영 체제의 경우 설치가 필요하지 않음)와 google-perftools 두 가지 소프트웨어 패키지를 설치해야 합니다. libunwind 라이브러리는 64 기반 프로그램에 대한 기본 함수 호출 체인 및 함수 호출 레지스터를 제공합니다. -비트 CPU 및 운영 체제. 다음은 Nginx를 최적화하기 위해 TCMalloc을 사용하는 구체적인 작업 프로세스를 설명합니다.
1) libunwind 라이브러리를 설치합니다.
http://download.savannah.gnu.org/releases/libunwind에서 해당 libunwind 버전을 다운로드할 수 있습니다. 여기에서 다운로드한 것은 libunwind-0.99-alpha.tar입니다. gz. 설치 과정은 다음과 같습니다
#tar zxvf libunwind-0.99-alpha.tar.gz
# cd libunwind-0.99-alpha/
#CFLAGS=-fPIC ./configure
#make CFLAGS=-fPIC
#make CFLAGS= -fPIC 설치
2) google-perftools
를 설치합니다. http://google-perftools.googlecode.com에서 해당 google-perftools 버전을 다운로드할 수 있습니다. 여기에서 다운로드한 것은 google-perftools-1.8.tar입니다. .gz. 설치 과정은 다음과 같습니다:
[root@localhost home]#tar zxvf google-perftools-1.8.tar.gz
[root@localhost home]#cd google-perftools-1.8/
[root@localhost google-perftools -1.8] # ./configure
[root@localhost google-perftools-1.8]#make && make install
[root@localhost google-perftools-1.8]#echo "/usr/
local/lib" > ld.so .conf.d/usr_local_lib.conf
[root@localhost google-perftools-1.8]# ldconfig
이제 google-perftools 설치가 완료되었습니다.
3) Nginx 재컴파일
Nginx가 google-perftools를 지원하려면 설치 과정에서 “–with-google_perftools_module” 옵션을 추가하여 Nginx를 재컴파일해야 합니다. 설치 코드는 다음과 같습니다:
[root@localhostnginx-0.7.65]#./configure
>--with-google_perftools_module --with-http_stub_status_module --prefix=/opt/nginx
[root@localhost nginx- 0.7.65 ]#make
[root@localhost nginx-0.7.65]#make install
여기서 Nginx 설치가 완료됩니다.
4) google-perftools
에 대한 스레드 디렉터리를 추가합니다. 스레드 디렉터리를 만들고 파일을 /tmp/tcmalloc에 배치합니다. 작업은 다음과 같습니다:
[root@localhost home]#mkdir /tmp/tcmalloc
[root@localhost home]#chmod 0777 /tmp/tcmalloc
5) Nginx 기본 구성 파일을 수정합니다
Modify nginx.conf 파일에서 pid 줄 아래에 다음 코드를 추가합니다.
#pidlogs/nginx.pid;
google_perftools_profiles /tmp/tcmalloc; 그런 다음 Nginx를 다시 시작하여 google-perftools 로드를 완료합니다.
6) 실행 상태 확인 google-perftools가 정상적으로 로드되었는지 확인하려면 다음 명령을 통해 확인할 수 있습니다.
[root@ localhost home]# lsof -n | grep tcmalloc
nginx 2395 아무도 9w REG 8,8 0 1599440 /tmp/tcmalloc.2395
nginx 2396 아무도 11w REG 8,8 0 1599443 /tmp/tcmalloc.2396
nginx 2397 아무도 13w REG 8,8 0 1599441 /tmp/tcmalloc.2397
nginx 2398 아무도 15w REG 8,8 0 1599442 /tmp/tcmalloc.2398
Nginx 구성 파일에서 Worker_processes 값이 4로 설정되어 있으므로 4개의 Nginx 스레드가 활성화되어 있으며 각 스레드에는 레코드 행이 있습니다. 각 스레드 파일 뒤의 숫자 값은 시작된 Nginx의 pid 값입니다.
이제 TCMalloc을 이용한 Nginx 최적화 작업이 완료되었습니다.
3. Nginx 커널 매개변수 최적화
커널 매개변수 최적화는 주로 Linux 시스템의 Nginx 애플리케이션에 대한 시스템 커널 매개변수 최적화입니다.
아래에 참고용으로 최적화 예시가 나와 있습니다.
net.ipv4.tcp_max_tw_buckets = 6000
net.ipv4.ip_local_port_range = 1024 65000
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_syncookies = 1
net.core.somaxconn = 262144
net.core.netdev_max_backlog = 262144
net.ipv4.tcp_max_orphans = 262144
net.ipv4.tcp_max_syn_backlog = 262144
net.ipv4.tcp_synack_retries = 1
net.ipv4.tcp_syn_ret ries = 1
net.ipv4.tcp_fin_timeout = 1
net .ipv4.tcp_keepalive_time = 30
위의 커널 매개변수 값을 /etc/sysctl.conf 파일에 추가한 후 다음 명령을 실행하여 적용합니다.
[root@ localhost home]#/sbin/sysctl -p
다음은 예제에서 옵션의 의미를 소개합니다.
TCP 매개변수 설정:
net.ipv4.tcp_max_tw_buckets: 옵션은 다음 작업에 사용됩니다. 대기 시간을 설정합니다. 기본값은 180 000 이고 여기서는 6000으로 설정됩니다.
net.ipv4.ip_local_port_range: 옵션은 시스템이 열 수 있는 포트 범위를 설정하는 데 사용됩니다. 동시성이 높은 상황에서는 그렇지 않으면 포트 번호가 충분하지 않습니다. NGINX가 프록시 역할을 하면 업스트림 서버에 대한 각 연결은 임시 또는 임시 포트를 사용합니다.
net.ipv4.tcp_tw_recycle: 옵션은 새로운 TCP 연결에 대해 timewait 빠른 재활용 을 활성화하는 데 사용됩니다.
net.ipv4.tcp_syncookies: 옵션은 SYN 쿠키를 설정하는 데 사용됩니다. SYN 대기 대기열이 오버플로되면 쿠키가 처리되도록 활성화됩니다.
net.ipv4.tcp_max_orphans: 옵션은 사용자 파일 핸들과 연결되지 않은 시스템의 최대 TCP 소켓 수를 설정하는 데 사용됩니다. 이 숫자를 초과하면 분리된 연결이 즉시 재설정되고 경고 메시지가 인쇄됩니다. 이 제한은 단순한 DoS 공격을 방지하기 위한 것입니다. 이 제한에 너무 의존하거나 이 값을 인위적으로 줄일 수도 없습니다. 대부분의 경우 이 값을 늘려야 합니다.
net.ipv4.tcp_max_syn_backlog: 옵션은 아직 클라이언트 확인 정보를 받지 못한 연결 요청의 최대값을 기록하는 데 사용됩니다. 이 매개변수의 기본값은 메모리가 128MB인 시스템의 경우 1024이고, 메모리가 작은 시스템의 경우 128입니다.
net.ipv4.tcp_synack_retries 매개변수의 값은 커널이 연결을 포기하기 전에 전송되는 SYN+ACK 패킷 수를 결정합니다. net.ipv4.tcp_syn_retries 옵션은 커널이 연결 설정을 포기하기 전에 전송된 SYN 패킷 수를 나타냅니다. net.ipv4.tcp_fin_timeout 옵션은 소켓이 FIN-WAIT-2 상태로 유지되는 시간을 결정합니다. 기본값은 60초입니다. 이 값을 올바르게 설정하는 것이 매우 중요합니다. 로드가 적은 웹 서버라도 데드 소켓 수가 많아 메모리 오버플로 위험이 있는 경우가 있습니다.
net.ipv4.tcp_syn_retries 옵션은 커널이 연결 설정을 포기하기 전에 전송된 SYN 패킷 수를 나타냅니다.
발신자가 소켓을 닫아야 하는 경우 net.ipv4.tcp_fin_timeout 옵션은 소켓이 FIN-WAIT-2 상태로 유지되는 기간을 결정합니다. 수신 측에서는 오류가 발생하고 연결이 닫히지 않거나 예기치 않게 충돌이 발생할 수도 있습니다.
net.ipv4.tcp_fin_timeout의 기본값은 60초입니다. 로드가 적은 웹 서버라도 데드 소켓이 많아 메모리 오버플로 위험이 있다는 점에 유의해야 합니다. FIN-WAIT-2는 최대 1.5KB의 메모리만 소비할 수 있기 때문에 FIN-WAIT-1보다 덜 위험하지만 수명이 더 깁니다.
net.ipv4.tcp_keepalive_time 옵션은 keepalive가 활성화되었을 때 TCP가 keepalive 메시지를 보내는 빈도를 나타냅니다. 기본값은 2(단위는 시간)입니다.
버퍼 큐:
net.core.somaxconn:옵션의 기본값은 128입니다. 이 매개변수는 시스템이 시작하는 TCP 연결 수를 조정하는 데 사용됩니다. 동시에 동시 요청 수가 많은 경우 기본값을 사용하면 링크 시간 초과 또는 재전송이 발생할 수 있으므로 이 값은 동시 요청 수에 맞춰 조정되어야 합니다.
NGINX에서 허용하는 숫자에 따라 결정됩니다. 기본값은 일반적으로 낮지만 NGINX는 매우 빠르게 연결을 수신하므로 허용 가능하지만 웹 사이트에 트래픽이 많은 경우 이 값을 늘려야 합니다. 커널 로그의 오류 메시지는 이 값이 너무 작다는 것을 알려주며 오류 메시지가 사라질 때까지 값을 늘립니다.
참고: 이 값을 512보다 크게 설정하면 그에 따라 NGINX Listen 명령의 백로그 매개변수도 변경해야 합니다.
net.core.netdev_max_backlog: 옵션은 각 네트워크 인터페이스가 커널이 처리할 수 있는 것보다 더 빠른 속도로 패킷을 수신할 때 대기열로 전송이 허용되는 최대 패킷 수를 나타냅니다.
4. PHP-FPM 최적화
로드가 많은 웹 사이트에서 PHP-FPM을 사용하여 FastCGI를 관리하는 경우 다음 팁이 유용할 수 있습니다.
1) FastCGI 프로세스 수 늘리기
PHP FastCGI를 넣어 자식 프로세스 수를 100개 이상으로 조정하세요. 4G 메모리가 있는 서버에서는 200개까지 사용할 수 있으므로 스트레스 테스트를 통해 최적의 값을 얻는 것이 좋습니다.
2) PHP-FPM 열린 파일 설명자 제한을 늘립니다.
rlimit_files 태그는 열린 파일 설명자에 대한 PHP-FPM 제한을 설정하는 데 사용됩니다. 기본값은 1024입니다. 이 레이블의 값은 Linux 커널의 열린 파일 수와 연결되어야 합니다. 예를 들어 이 값을 65 535로 설정하려면 Linux 명령줄에서 "ulimit -HSn 65536"을 실행해야 합니다. H 그런 다음 加 PHP-FPM을 추가하여 파일 설명자 제한을 엽니다:
# vi /path/to/php-fpm.conf 찾기 "& lt; value =" rlimit_files "& gt; 1024 & lt;/value & gt;" " 1024를 4096 이상으로 변경하세요
. PHP-FPM을 다시 시작하세요.
ulimit -n을
65536 이상으로 조정하세요. 이 매개변수를 조정하는 방법은 인터넷의 일부 기사를 참조할 수 있습니다. 수정하려면 명령줄에서 ulimit -n 65536을 실행하세요. 수정할 수 없는 경우 /etc/security/limits.conf를 설정하고 * hard nofile65536
* Soft nofile 65536
3) max_re을 적절하게 늘리십시오. Quests
max_requests 태그는 각 자녀가 닫히기 전에 처리할 수 있는 최대 요청 수를 지정합니다. 기본 설정은 500입니다.
500
5.nginx.conf 매개변수 최적화
nginx 시작되는 프로세스 수는 일반적으로 총 프로세스 수와 같습니다. 실제로 CPU의 코어는 일반적으로 4개 또는 8개를 사용할 수 있습니다. 각 nginx 프로세스에서 소비하는 메모리는 10MB입니다.
worker_cpu_affinity
Linux에만 해당됩니다. 이 옵션을 사용하여 작업자 프로세스와 CPU를 바인딩합니다(2.4 커널이 있는 시스템에서는 사용할 수 없음)
CPU가 8개인 경우 할당은 다음과 같습니다.
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000
00100000 01000000 10000000
nginx는 다음과 같은 이유로 여러 작업자 프로세스를 사용할 수 있습니다.
SMP를 사용하기 위해
작업자가 디스크 I/O에서 차단할 때 대기 시간을 줄이기 위해
select()/poll()이
사용될 때 프로세스당 연결 수를 제한하기 위해 이벤트 섹션
의 Worker_processes 및 Worker_connections를 사용하면 maxclients 값을 계산할 수 있습니다: k max_clients = 작업자_프로세스 * 작업자_연결
worker_rlimit_nofile 102400;
각 nginx 프로세스에 대한 최대 열린 파일 설명자 수 구성은 시스템의 단일 프로세스에 대한 열린 파일 수와 일치해야 합니다. 2.6 커널은 65535이므로 nginx가 예약되면 작업자_rlimit_nofile은 65535로 채워져야 합니다. 프로세스에 대한 요청 수가 균형을 이루지 못하여 제한을 초과하면 502 오류가 반환됩니다. 제가 여기에 쓴 내용은 조금 더 큽니다
epoll을 사용하세요
Nginx는 최신 epoll(Linux 2.6 커널)과 kqueue(freebsd) 네트워크 I/O 모델을 사용하는 반면 Apache는 기존 선택 모델을 사용합니다.
많은 연결의 읽기 및 쓰기를 처리하기 위해 Apache에서 채택한 선택 네트워크 I/O 모델은 매우 비효율적입니다. 동시성이 높은 서버에서 I/O 폴링은 가장 시간이 많이 걸리는 작업입니다. 현재 Linux는 액세스되는 Squid와 Memcached 모두 epoll 네트워크 I/O 모델을 사용합니다.
worker_processes NGINX 작업자 프로세스 수(기본값은 1) 대부분의 경우 CPU 코어당 하나의 작업자 프로세스를 실행하는 것이 가장 좋으며 이 명령을 자동으로 설정하는 것이 좋습니다. 때로는 작업자 프로세스가 많은 디스크 I/O를 수행해야 하는 경우와 같이 이 값을 늘리고 싶을 수도 있습니다.
worker_connections 65535; 작업자 프로세스당 허용되는 최대 동시 연결 수(Maxclient = work_processes * Worker_connections)
keepalive_timeout 75 Keepalive 시간 초과
여기에 참고할 공식 문장이 있습니다. ：
매개변수 할 수 있다 Line Keep-Alive:
timeout=time은 Mozilla와 Konqueror를 이해합니다. MSIE 자체는
keep-alive 연결을 약 60초 후에 종료합니다.
고객 요청 헤더 버퍼 크기 nginx는 기본적으로 client_header_buffer_size 버퍼를 사용합니다. 헤더 값이 너무 큰 경우에는 Large_client_header_buffers를 사용하여 읽습니다. HTTP 헤더/쿠키가 너무 작게 설정되면 400 오류 nginx 400 잘못된 요청이 보고됩니다 요청이 버퍼를 초과하면, HTTP 414 오류(URI가 너무 김)가 보고됩니다. nginx에서 허용하는 가장 긴 HTTP 헤더 크기는 버퍼 중 하나보다 커야 합니다. 그렇지 않으면 400 HTTP 오류(잘못된 요청)가 보고됩니다.
open_file_cache max 102400
사용 필드: http, server, location 이 지시어는 캐시 활성화 여부를 지정합니다. 활성화되면 파일에 대한 다음 정보가 기록됩니다. ·열린 파일 설명자, 크기 정보 및 수정 시간. ·기존 디렉토리 메시지 · 파일 검색 중 오류 메시지 - 이 파일이 없으면 올바르게 읽을 수 없습니다. open_file_cache_errors 지시어 옵션을 참조하세요.
· max - 캐시가 오버플로되는 경우 가장 오래 사용되는 파일인 최대 캐시 수를 지정합니다. (LRU) 제거됨
예: open_file_cache max=1000 inactive=20s; open_file_cache_min_uses 2; open_file_cache_errors on;
open_file_cache_errors
구문: open_file_cache_errors on | off 기본값: open_file_cache_errors off 필드: http, 서버, 위치 지시어는 파일을 검색할 때 캐시 오류를 기록할지 여부를 지정합니다. open_file_cache_min_uses
구문: open_file_cache_min_uses 숫자 기본값: open_file_cache_min_uses 1 사용 필드: http, 서버, 위치 이 지시어는 잘못된 매개변수에서 특정 시간 범위를 지정합니다. open_file_cache 지시어입니다. 더 큰 값을 사용하면 파일 설명자가 항상 캐시에 열려 있습니다.
open_file_cache_valid
구문: open_file_cache_valid 60 사용되는 필드: http, server, location 이 지시어는 open_file_cache에서 캐시된 항목의 유효한 정보를 확인해야 하는 경우를 지정합니다.
gzip on
gzip_buffers 4 16k; gzip_types 텍스트/ 일반 애플리케이션/x- javascript 텍스트/ cssapplication/xml;
gzip_vary on;
캐시 정적 파일:
location ~* ^.+.(swf|gif|png|jpg|js|css)$ {
root /usr/local/ku6 /ktv/show.ku6.com/;
만료 1분;
}
응답 버퍼:
예를 들어 Nginx+Tomcat 프록시 액세스 JS는 완전히 로드될 수 없습니다. . 이 매개변수는 다음에 영향을 미칩니다. proxy_buffer_size 128k;
Proxy_buffers 32 128k;
Proxy_busy_buffers_size 128k;
Nginx는 해당 서비스를 프록시한 후 또는 우리가 구성한 UpStream 및 위치를 기반으로 해당 파일을 얻습니다. 먼저 파일은 nginx의 메모리 또는 임시 파일 디렉터리로 구문 분석됩니다. , 그러면 nginx가 응답합니다. 그런 다음 Proxy_buffers, Proxy_buffer_size 및 Proxy_busy_buffers_size가 너무 작으면 nginx 구성에 따라 콘텐츠가 임시 파일로 생성되지만 임시 파일의 크기에도 기본값이 있습니다. 따라서 이 4가지 값이 너무 작으면 일부 파일의 일부만 로드됩니다. 따라서,proxy_buffers,proxy_buffer_size,proxy_busy_buffers_size,proxy_temp_file_write_size는 당사 서버 상황에 맞게 적절하게 조정되어야 합니다. 구체적인 매개변수의 세부 사항은 다음과 같습니다.
proxy_buffers 32 128k; 32개의 버퍼 영역이 설정되며, 각 크기는 128k입니다.
proxy_buffer_size 128k, 두 값이 일 때 각 버퍼 영역의 크기는 128k입니다. 불일치, 특정 정보를 찾을 수 없음 위 설정과 일치하는 것이 효과적입니까?
proxy_busy_buffers_size 128k; 사용 중인 버퍼 영역의 크기를 설정하고 최대
proxy_temp_file_write_size 캐시 파일 크기를 제어합니다.
6. 액세스 로그 최적화
각 요청 회의 기록 CPU 소모 그리고 나/ O 주기. 이러한 영향을 줄이는 한 가지 방법은 액세스 로그를 버퍼링하는 것입니다. NGINX는 각 로그 레코드에 대해 별도의 쓰기 작업을 수행하는 대신 버퍼링을 사용하여 일련의 로그 레코드를 버퍼링하고 단일 작업으로 이를 파일에 함께 씁니다.
액세스 로그 캐시를 활성화하려면 access_log 지시어에 buffer=size 매개변수를 포함해야 합니다. 버퍼가 크기 값에 도달하면 NGINX는 버퍼의 내용을 로그에 기록합니다. 지정된 기간 후에 NGINX가 캐시에 쓰도록 하려면 플러시=시간 매개변수를 포함합니다. 두 매개변수가 모두 설정되면 NGINX는 다음 로그 항목이 버퍼 값을 초과하거나 버퍼의 로그 항목이 설정된 시간 값을 초과할 때 해당 항목을 로그 파일에 기록합니다. 이는 작업자 프로세스가 로그 파일을 다시 열거나 종료할 때도 기록됩니다. 액세스 로깅을 완전히 비활성화하려면 access_log 지시어를 off 매개변수로 설정하세요.
7. 현재 제한
사용자가 너무 많은 리소스를 소비하지 않도록 하고 시스템 성능, 사용자 경험 및 보안에 영향을 미치지 않도록 여러 제한을 설정할 수 있습니다. 관련 지시문은 다음과 같습니다.
limit_conn 및limit_conn_zone: NGINX는 단일 IP 주소에서의 연결과 같은 고객 연결 수에 대한 제한을 허용합니다. 이러한 지시문을 설정하면 단일 사용자가 너무 많은 연결을 열고 사용할 수 있는 것보다 더 많은 리소스를 소비하는 것을 방지할 수 있습니다.
limit_rate: 클라이언트에 대한 전송 응답 속도 제한입니다(여러 연결을 여는 각 클라이언트는 더 많은 대역폭을 소비합니다). 이 제한을 설정하면 시스템 과부하를 방지하고 모든 클라이언트에 대해 보다 균일한 서비스 품질을 보장할 수 있습니다.
limit_req 및limit_req_zone: limit_rate와 동일한 기능을 갖는 NGINX 처리 요청에 대한 속도 제한입니다. 너무 느린 프로그램이 애플리케이션 요청(예: DDoS 공격)을 덮어쓰는 것을 방지하기 위해 사용자 제한 요청 비율에 합리적인 값을 설정하면 특히 로그인 페이지의 보안을 향상시킬 수 있습니다.
max_conns: 업스트림 구성 블록의 서버 명령 매개변수입니다. 업스트림 서버 그룹에서 단일 서버가 허용할 수 있는 최대 동시성 수입니다. 업스트림 서버의 과부하를 방지하려면 이 제한을 사용하십시오. 값을 0(기본값)으로 설정하면 제한이 없음을 의미합니다. queue(NGINX Plus):
최대 max_cons 제한을 초과하는 업스트림 서버의 요청 수를 저장하기 위해 대기열을 만듭니다. 이 지시문은 대기 중인 요청의 최대 수를 설정하고 선택적으로 오류를 반환하기 전 최대 대기 시간을 설정합니다(기본값은 60초). 이 지시문을 생략하면 요청이 대기열에 추가되지 않습니다.
VII. 오류 문제 해결
1. Nginx 502 잘못된 게이트웨이:
게이트웨이나 프록시로 작동하는 서버가 요청을 실행하려고 하면 업스트림 서버. 일반적인 이유:
1. 백엔드 서비스가 중단되면 직접 502(nginx 오류 로그: connect() 실패(111: 연결이 거부됨)) 2. 백엔드 서비스가 다시 시작됩니다
예: 백엔드 서비스 교체 이를 끄고 nginx의 백엔드 인터페이스에 요청을 보내면 nginx 로그에서 502 오류를 볼 수 있습니다.
nginx+php에서 502가 발생하면 오류 분석:
php-cgi 프로세스 수가 충분하지 않거나, php 실행 시간이 길거나(mysql이 느림), php-cgi 프로세스가 종료되면 502 오류가 발생합니다. 발생
일반적으로 Nginx 502 Bad Gateway는 php-fpm.conf 설정과 관련이 있고, Nginx 504 Gateway Time-out은 nginx.conf 설정과 관련이 있습니다.
1) 현재 PHP FastCGI 프로세스 수가 몇 개인지 확인하세요. 충분함:
netstat -anpo | grep "php-cgi" | wc -l
사용된 "FastCGI 프로세스 수"가 기본 "FastCGI 프로세스 수"에 가깝다면 이는 "FastCGI 프로세스 수"를 의미합니다. FastCGI 프로세스"로는 충분하지 않으며 늘려야 합니다.
2) 일부 PHP 프로그램의 실행 시간은 Nginx의 대기 시간을 초과합니다. nginx.conf 구성 파일에서 FastCGI의 시간 초과 시간을 적절하게 늘릴 수 있습니다. 예:
http {
... fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
......
}
2, 504 게이트웨이 시간 초과:
nginx 서버가 게이트웨이로 작동하거나 프록시가 수행을 시도합니다. 요청, 업스트림 서버(HTTP, FTP, LDAP와 같은 URI로 식별되는 서버)로부터 적시에 응답을 받지 못했습니다. 일반적인 이유:
이 인터페이스는 시간이 너무 많이 걸립니다. 백엔드 서비스가 요청을 수신하고 실행을 시작하지만 설정된 시간 내에 nginx에 데이터를 반환하지 못합니다. 백엔드 서버의 전체 부하가 너무 높습니다. . 요청을 받은 후, 바쁜 스레드로 인해 요청에 대한 인터페이스를 정렬할 수 없어 설정된 시간에 nginx에 데이터를 반환하지 못했습니다
2, 413 요청 엔터티가 너무 큼
해결 방법: client_max_body_size 클라이언트 _max_body_size: 지시문은 요청 헤더의 Content-Length 필드에 나타나는 클라이언트 연결에 허용되는 최대 요청 엔터티 크기를 지정합니다. 클라이언트는 "요청 엔터티가 너무 큼"(413) 오류를 받게 됩니다. 브라우저는 이 오류를 표시하는 방법을 알지 못합니다.
php.ini에서
post_max_size 및 upload_max_filesize를 늘리세요
3. 나타납니다: 업스트림에서 응답 헤더를 읽는 동안 너무 큰 헤더를 보냈습니다. 오류
1) nginx 역방향 프록시인 경우 헤더가 다음과 같은 경우 프록시는 nginx에서 클라이언트로 사용됩니다. 너무 커서 기본 1k를 초과하면 위의 업스트림에서 너무 큰 헤더를 전송하게 됩니다(직설적으로 말하면). 이는 nginx가 백엔드 서버에 외부 요청을 보내는 데 의해 발생하며 백엔드 서버에서 반환된 헤더는 다음과 같습니다. nginx가 처리하기에는 너무 큽니다.
위치 / {
#다음 3줄을 추가하세요.
Proxy_buffer_size 64k; Proxy_buffers 32 32k;
Proxy_set_header 호스트 $host; Proxy_set_header X -Real-IP $remote_addr;proxy_set_head erX- Forwarded-For $proxy_add_x_forwarded_for;
}
}
2) nginx+PHPcgi
인 경우 오류는 업스트림에 있습니다: "fastcgi://127.0.0.1:9000 ". 그냥
더 추가하세요:
fastcgi_buffer_size 128k; fastcgi_buffers 4 128k;
server { server_name ddd.com; index index.html index.htm index.php;
client_header_buffer_size 128k; Large_client_header_buffers 4 128k;
Proxy_buffer_size 64k; Proxy_buffers 8 64k; fastcgi_buffer_size 128k;
fastcgi_buffers 4 128k;
위치 / {
ㅋㅋㅋ 종종 역방향 프록시로 사용되며 PHP 작동을 매우 잘 지원할 수도 있습니다. 80sec에서는 기본적으로 서버가 PHP의 모든 유형의 파일을 잘못 구문 분석할 수 있으며 이로 인해 악의적인 공격자가 PHP 서버를 지원하는 nginx를 손상시킬 수 있음을 발견했습니다.
취약점 분석: nginx는 기본적으로 cgi 모드에서 실행되는 PHP를 지원합니다. 예를 들어 구성 파일에서
location ~ .php$ {<!-- --><p> root html;</p> fastcgi_pass 127.0을 사용할 수 있습니다. 0.1:9000 ;<p> fastcgi_index index.php;</p> fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;<p> include fastcgi_params;</p> }
위치 선택 시 URI 환경 변수를 사용하여 요청을 선택합니다. 백엔드 Fastcgi에 전달된 핵심 변수 SCRIPT_FILENAME은 nginx에서 생성된 $fastcgi_script_name에 의해 결정됩니다. 분석을 통해 $fastcgi_script_name이 URI 환경 변수에 의해 직접 제어되는 것을 볼 수 있습니다. PATH_INFO 추출을 더 잘 지원하기 위해 cgi.fix_pathinfo 옵션이 PHP 구성 옵션에 존재합니다. 그 목적은 SCRIPT_FILENAME에서 실제 스크립트 이름을 추출하는 것입니다. 따라서 http://www.80sec.com/80sec.jpg가 있다고 가정하면 다음과 같은 방법으로 http://www.80sec.com/80sec.jpg/80sec.php
에 액세스하여 URI
/80sec.jpg/80sec.php
위치 명령 후 요청은 처리를 위해 백엔드 fastcgi로 전달되고 nginx는 이에 대한 환경 변수 SCRIPT_FILENAME을 다음과 같이 설정합니다.
/scripts /80sec.jpg/80sec.phplocation ~ .php$ {<!-- --><br> root html;<br> fastcgi_pass 127.0.0.1:9000;<br> fastcgi_index index.php;<br> fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;<br> include fastcgi_params;<br> }
的方式支持对php的解析，location对请求进行选择的时候会使用URI环境变量进行选择，其中传递到后端Fastcgi的关键变量SCRIPT_FILENAME由nginx生成的$fastcgi_script_name决定，而通过分析可以看到$fastcgi_script_name是直接由URI环境变量控制的，这里就是产生问题的点。而为了较好的支持PATH_INFO的提取，在PHP的配置选项里存在cgi.fix_pathinfo选项，其目的是为了从SCRIPT_FILENAME里取出真正的脚本名。
那么假设存在一个http://www.80sec.com/80sec.jpg，我们以如下的方式去访问
http://www.80sec.com/80sec.jpg/80sec.php
将会得到一个URI
/80sec.jpg/80sec.php
经过location指令，该请求将会交给后端的fastcgi处理，nginx为其设置环境变量SCRIPT_FILENAME，内容为
/scripts/80sec.jpg/80sec.php
而在其他的webserver如lighttpd当中，我们发现其中的SCRIPT_FILENAME被正确的设置为
/scripts/80sec.jpg
所以不存在此问题。
后端的fastcgi在接受到该选项时，会根据fix_pathinfo配置决定是否对SCRIPT_FILENAME进行额外的处理，一般情况下如果不对fix_pathinfo进行设置将影响使用PATH_INFO进行路由选择的应用，所以该选项一般配置开启。Php通过该选项之后将查找其中真正的脚本文件名字，查找的方式也是查看文件是否存在，这个时候将分离出SCRIPT_FILENAME和PATH_INFO分别为
/scripts/80sec.jpg和80sec.php
最后，以/scripts/80sec.jpg作为此次请求需要执行的脚本，攻击者就可以实现让nginx以php来解析任何类型的文件了。
POC： 访问一个nginx来支持php的站点，在一个任何资源的文件如robots.txt后面加上/80sec.php，这个时候你可以看到如下的区别：
访问http://www.80sec.com/robots.txt
HTTP/1.1 200 OK<br> Server: nginx/0.6.32<br> Date: Thu, 20 May 2010 10:05:30 GMT<br> Content-Type: text/plain<br> Content-Length: 18<br> Last-Modified: Thu, 20 May 2010 06:26:34 GMT<br> Connection: keep-alive<br> Keep-Alive: timeout=20<br> Accept-Ranges: bytes
访问访问http://www.80sec.com/robots.txt/80sec.php
HTTP/1.1 200 OK<br> Server: nginx/0.6.32<br> Date: Thu, 20 May 2010 10:06:49 GMT<br> Content-Type: text/html<br> Transfer-Encoding: chunked<br> Connection: keep-alive<br> Keep-Alive: timeout=20<br> X-Powered-By: PHP/5.2.6
其中的Content-Type的变化说明了后端负责解析的变化，该站点就可能存在漏洞。
漏洞厂商：http://www.nginx.org
解决方案：
我们已经尝试联系官方，但是此前你可以通过以下的方式来减少损失
关闭cgi.fix_pathinfo为0
或者
if ( $fastcgi_script_name ~ ..*/.*php ) {<!-- --><br> return 403;<br> }의 내용 lighttpd와 같은 다른 웹서버에서는 SCRIPT_FILENAME이
/scripts/80sec.jpg로 올바르게 설정되어 있음을 발견했습니다. > 그래서 존재하지 않는 문제입니다.
백엔드 fastcgi가 이 옵션을 받으면 fix_pathinfo 구성을 기반으로 SCRIPT_FILENAME에 대한 추가 처리를 수행할지 여부를 결정합니다. 일반적으로 fix_pathinfo가 설정되지 않으면 라우팅에 PATH_INFO를 사용하는 애플리케이션에 영향을 미치므로 이 옵션은 일반적으로 다음과 같이 구성됩니다. 켜져 있습니다. 이 옵션을 전달하면 Php는 실제 스크립트 파일 이름을 검색합니다. 이때 파일이 존재하는지 확인하는 방법도 있습니다. 이때 SCRIPT_FILENAME과 PATH_INFO는 /scripts/80sec.jpg 및 80sec로 구분됩니다. .php
마지막으로 /scripts/80sec.jpg를 이 요청에 대해 실행해야 하는 스크립트로 사용하면 공격자는 nginx가 PHP를 사용하여 모든 유형의 파일을 구문 분석하도록 할 수 있습니다. 🎜🎜POC: nginx가 PHP를 지원하는 사이트를 방문하세요. robots.txt와 같은 리소스 파일 뒤에 /80sec.php를 추가하면 다음과 같은 차이점을 볼 수 있습니다. 🎜🎜http://www.80sec.com을 방문하세요. /robots.txt🎜🎜HTTP/1.1 200 OK🎜 서버: nginx/0.6.32🎜 날짜: 2010년 5월 20일 목요일 10:05:30 GMT🎜 콘텐츠 유형: text/plain🎜 콘텐츠 길이: 18 🎜 최종 수정: 2010년 5월 20일 목요일 06:26:34 GMT🎜 연결: keep-alive🎜 Keep-Alive: timeout=20🎜 Accept-Ranges: bytes🎜🎜 http:// /www를 방문하세요. 80sec.com/robots.txt/80sec.php🎜🎜HTTP/1.1 200 OK🎜 서버: nginx/0.6.32🎜 날짜: 2010년 5월 20일 목요일 10:06:49 GMT🎜 콘텐츠 유형: text/ html🎜 Transfer-Encoding: Chunked🎜 연결: keep-alive🎜 Keep-Alive: timeout=20🎜 X-Powered-By: PHP/5.2.6🎜🎜 콘텐츠 유형 변경에 대한 설명 백엔드가 담당하는 경우 변경 사항을 구문 분석하면 사이트가 취약해질 수 있습니다. 🎜🎜취약점 공급업체: http://www.nginx.org🎜🎜해결책: 🎜🎜공식 담당자에게 연락을 시도했지만 그 전에 다음 방법을 통해 손실을 줄일 수 있습니다🎜🎜cgi.fix_pathinfo를 닫습니다. 0🎜🎜 또는 🎜🎜<code>if ( $fastcgi_script_name ~ ..*/.*php ) {<!-- -->🎜 return 403;🎜 }🎜🎜PS: 감사합니다 laruence Daniel 분석 과정에서 도움을 주세요🎜🎜🎜위 내용은 'Xiaobai'는 Nginx의 모듈과 작동 원리를 이해하도록 안내합니다! ! !의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
