Nginx 구성 파일 구문 분석

Nginx가 설치되면 해당 설치 디렉터리가 생성됩니다. 이전 설치 경로에 따르면 Nginx 구성 파일 경로는 /opt/nginx/conf이며 여기서 nginx.conf가 기본 구성입니다. Nginx의 파일입니다. 여기서는 nginx.conf 구성 파일에 중점을 둡니다.
Nginx 구성 파일은 주로 기본(전역 설정), 서버(호스트 설정), 업스트림(로드 밸런싱 서버 설정) 및 위치(URL이 특정 위치에 대한 설정과 일치)의 네 부분으로 나뉩니다. 주요 부분에 설정된 지침은 다른 모든 설정에 영향을 미칩니다. 서버 부분의 지침은 주로 호스트 및 포트를 지정하는 데 사용됩니다. 업스트림 지침은 주로 일련의 백엔드 서버를 설정하는 데 사용됩니다. 위치 부분은 웹페이지의 위치를 ​​일치시키는 데 사용됩니다. 네 가지 관계: 서버는 기본을 상속하고 위치는 서버를 상속하며 업스트림은 다른 설정을 상속하거나 상속하지 않습니다.
이 네 부분 중 각 부분에는 여러 지침이 포함되어 있습니다. 이러한 지침에는 주로 Nginx의 기본 모듈 지침, 이벤트 모듈 지침 및 HTTP 코어 모듈 지침이 포함됩니다. Http SSL 모듈, HttpGzip Static 모듈, Http Addition 모듈 등과 같은 기타 HTTP 모듈 지침을 사용할 수 있습니다.
다음은 Nginx 구성 예제를 사용하여 nginx.conf의 각 명령어의 의미를 자세히 소개합니다. Nginx의 구조와 각 구성 옵션의 의미를 보다 명확하게 이해하기 위해 Nginx 구성 파일을 기능 포인트에 따라 7개 부분으로 나누어서 하나씩 설명합니다.

1. Nginx의 글로벌 구성
다음 내용은 Nginx의 글로벌 속성 구성입니다.

[html] 보다 일반 사본

1. user none none
2. worker_processes 4 🎜>error_log 로그/error.log 통지;
3. pid 로그/nginx.pid
이벤트{
epoll 사용; >
5. Worker_connections 65536; }
6. 위 코드에서 각 구성 옵션의 의미는 다음과 같습니다.
7. user는 지정된 기본 모듈 명령입니다. Nginx Worker 프로세스는 사용자 및 사용자 그룹으로 실행되며 기본적으로는 아무도 계정으로 실행됩니다.
8. worker_processes는 Nginx에서 열 프로세스 수를 지정하는 기본 모듈 명령입니다. 각 Nginx 프로세스는 평균 10M~12M의 메모리를 소비합니다. 경험에 따르면 일반적으로 하나의 프로세스를 지정하는 것으로 충분합니다. 멀티 코어 CPU인 경우 CPU 수와 동일한 수의 프로세스를 지정하는 것이 좋습니다.
error_log는 전역 오류 로그 파일을 정의하는 데 사용되는 기본 모듈 지시문입니다. 로그 출력 수준에는 선택할 수 있는 디버그, 정보, 알림, 경고, 오류 및 비판이 포함됩니다. 그 중에서 디버그 출력 로그가 가장 상세하고 비판 출력 로그가 가장 낮습니다.
9. pid는 프로세스 ID의 저장 파일 위치를 지정하는 데 사용되는 기본 모듈 명령입니다.

worker_rlimit_nofile은 nginx 프로세스에서 열 수 있는 최대 파일 설명자 수를 지정하는 데 사용됩니다. 여기서는 65535입니다. 이를 설정하려면 "ulimit -n 65535" 명령을 사용해야 합니다.
events 명령은 Nginx의 작동 모드와 연결 수의 상한을 설정하는 것입니다.

[html] 보기 일반 사본

이벤트{

epoll 사용
작업자 연결 65536;

}

1. 
   use는 Nginx의 작업 모드를 지정하는 데 사용되는 이벤트 모듈 명령입니다. Nginx에서 지원하는 작업 모드는 select, poll, kqueue, epoll, rtsig 및 /dev/poll입니다. 그 중 select와 poll은 모두 표준 작업 모드이고 kqueue와 epoll은 효율적인 작업 모드입니다. 차이점은 epoll은 Linux 플랫폼에서 사용되는 반면 kqueue는 BSD 시스템에서 사용된다는 것입니다. Linux 시스템의 경우 epoll 작업 모드가 첫 번째 선택입니다.
   worker_connections는 각 Nginx 프로세스에 대한 최대 연결 수를 정의하는 데 사용되는 이벤트 모듈 지시문이기도 합니다. 기본값은 1024입니다. 최대 클라이언트 연결 수는 작업자_프로세스 및 작업자_연결에 의해 결정됩니다. , Max_client=worker_processes*worker_connections, 역방향 프록시로 작동할 때 max_clients는 max_clients가 됩니다. = 작업자_프로세스 * 작업자_연결/4.
   프로세스의 최대 연결 수는 Linux 시스템 프로세스의 최대 열린 파일 수에 의해 제한됩니다. 작업자_연결 설정은 운영 체제 명령 "ulimit -n을 실행한 후에만 적용됩니다. 65536".

   2. HTTP 서버 구성
   다음으로 HTTP 서버 설정을 시작합니다.
   다음 내용은 Nginx의 HTTP 서버 관련 속성 구성입니다.
   

   [html] 보기 일반 사본

   1. http{
   2. include conf/mime.types; >default_type 애플리케이션/옥텟-스트림
   3. log_format main '$remote_addr - $remote_user [$time_local] ' $request" $status $bytes_sent '
   4. '"$http_referer" "$http_user_agent" '
   5. '"$gzip_ratio"'; $remote_addr - $remote_user [$time_local] '
   6. '"$request" $status $bytes_sent '
   7. '"$http_referer" " $http_user_agent" '
   8. '"$http_range" "$sent_http_content_range"';
   9. client_max_body_size 20m;
   10. client_header_buffer_size 32K; >
   11. 파일 보내기
   12. tcp_nopush on;
   keepalive_timeout 60;
   13. client_header_timeout 10;
   14. client_body_timeout 10;
   15. 다음은 이 코드의 각 구성 옵션의 의미에 대한 자세한 소개입니다. include는 구성 파일에 포함된 파일을 설정하고 기본 구성 파일의 복잡성을 줄일 수 있는 기본 모듈 지시문입니다. Apache의 include 메소드와 유사합니다. default_type은 HTTP 핵심 모듈 지시문에 속합니다. 여기서 기본 유형은 파일 유형이 정의되지 않은 경우 사용되는 바이너리 스트림으로 설정됩니다. 예를 들어 PHP 환경이 구성되지 않은 경우 Nginx는 이를 구문 분석하지 않습니다. 이때, 브라우저를 통해 PHP 파일에 접근하면 다운로드 창이 나타납니다.
   다음 코드는 로그 형식 설정을 구현합니다.
   17. [html] 보기 일반 사본
   18. log_format main '$remote_addr - $remote_user [$time_local] '
   '"$request " $status $bytes_sent '
   '"$http_referer" "$http_user_agent" '
   '"$gzip_ratio"';
   
   

   log_format 다운로드 '$remote_addr - $remote_user [$time_local] '
   
   
   
   '"$request" $status $bytes_sent '

   '"$http_referer" "$http_user_agent" '

   1. '"$http_range" "$sent_http_content_range"' >
      log_format은 Nginx 로그의 출력 형식을 지정하는 데 사용되는 Nginx의 HttpLog 모듈 명령입니다. main아래의 access_log 지시문에서 참조할 수 있는 이 로그 출력 형식의 이름입니다.
      client_max_body_size는 클라이언트가 요청할 수 있는 단일 파일의 최대 바이트 수를 설정하는 데 사용됩니다.
      client_header_buffer_size는 클라이언트 요청 헤더에서 헤더 버퍼 크기를 지정하는 데 사용됩니다. 대부분의 요청의 경우 버퍼 크기는 1K이면 충분합니다. 메시지 헤더를 사용자 정의하거나 더 큰 쿠키가 있는 경우 버퍼 크기를 늘릴 수 있습니다. 32K로 설정되어 있습니다.
      large_client_header_buffers는 클라이언트 요청에서 더 큰 메시지 헤더에 대한 최대 캐시 수와 크기를 지정하는 데 사용됩니다. "4"는 숫자이고, "128K"는 크기이며, 최대 캐시 양은 4입니다. 128K.
      sendfile 매개변수는 효율적인 파일 전송 모드를 활성화하는 데 사용됩니다. 네트워크 차단을 방지하려면 tcp_nopush 및 tcp_nodelay 명령을 on으로 설정하십시오.
      keepalive_timeout은 클라이언트 연결이 유지되는 시간 제한을 설정합니다. 이 시간이 지나면 서버는 연결을 닫습니다.
      client_header_timeout은 클라이언트 요청 헤더 읽기 시간 제한을 설정합니다. 이 시간이 초과되고 클라이언트가 데이터를 전송하지 않은 경우 Nginx는 "요청 시간 초과(408)" 오류를 반환합니다.
      client_body_timeout은 클라이언트 요청 본문 읽기 시간 초과를 설정합니다. 이 시간이 초과되고 클라이언트가 데이터를 전송하지 않은 경우 Nginx는 "요청 시간 초과(408)" 오류를 반환합니다. 기본값은 60입니다.
      send_timeout은 클라이언트에 응답하기 위한 시간 초과 기간을 지정합니다. 이 시간 초과는 두 연결 활동 사이의 시간으로 제한됩니다. 클라이언트의 활동 없이 이 시간이 초과되면 Nginx는 연결을 닫습니다.

      3.HttpGzip 모듈 구성
      아래 Nginx의 HttpGzip 모듈을 구성합니다. 이 모듈은 출력 데이터 스트림의 온라인 실시간 압축을 지원합니다. 이 모듈이 설치되어 있는지 확인하려면 다음 명령을 사용하십시오:
      

      [html] view 일반 사본

      1. [root@localhost conf]# /opt/nginx/sbin/nginx -V
      2. nginx 버전: nginx/0.7.65
      3. 인수 구성: --with-http_stub_status_module --with-http_gzip_static_module --prefix=/opt/nginx
      
      /opt/nginx/sbin/nginx -V 명령을 통해 Nginx를 설치할 때 컴파일 옵션을 볼 수 있습니다. HttpGzip 모듈을 설치했는지 확인하세요.
      다음은 Nginx 구성에서 HttpGzip 모듈의 관련 속성 설정입니다.
      

      [html] 보기 일반 사본

      1. gzip 켜기
      2. gzip_min_length 1k >gzip_buffers 4 16k; gzip_http_version 1.1; gzip_types text/ plain application/x-javascript text/css application/xml;
      3. gzip_vary on; on"은 GZIP 압축을 켜고 출력 데이터 스트림을 실시간으로 압축하는 것을 의미합니다.
      4. gzip_min_length는 압축이 허용되는 페이지의 최소 바이트 수를 설정합니다. 페이지 바이트 수는 헤더의 Content-Length에서 가져옵니다. 기본값은 0이며, 크기에 관계없이 페이지를 압축합니다. 바이트 수는 1K보다 크게 설정하는 것이 좋습니다. 1K보다 작을 경우 바이트 수가 점점 더 많아질 수 있습니다.
      5. gzip_buffers는 압축 결과 스트림 캐시로 4개 단위의 16K 메모리를 적용한다는 의미입니다. 기본값은 gzip 압축 결과를 저장하기 위해 원본 데이터 크기와 동일한 메모리 공간을 적용한다는 것입니다.
      gzip_http_version은 HTTP 프로토콜 버전을 설정하고 식별하는 데 사용됩니다. 기본값은 1.1입니다. 현재 대부분의 브라우저는 이미 GZIP 압축 해제를 지원하므로 기본값을 사용하세요.
      6. gzip_comp_level은 GZIP 압축 비율을 지정하는 데 사용됩니다. 1은 압축 비율이 가장 작고 처리 속도가 가장 빠릅니다. 9는 압축 비율이 가장 크고 전송 속도가 빠르지만 처리 속도가 가장 느리고 CPU를 더 많이 소비합니다. 자원.
      7. gzip_types는 압축 유형을 지정하는 데 사용됩니다. 지정 여부에 관계없이 "text/html" 유형은 항상 압축됩니다.
      gzip_vary 옵션을 사용하면 프런트엔드 캐시 서버가 GZIP 압축 페이지를 캐시할 수 있습니다. 예를 들어 Squid를 사용하여 Nginx 압축 데이터를 캐시할 수 있습니다.
      4. 로드밸런싱 구성 아래 로드밸런싱 서버 목록을 설정합니다.
      

      [html] 보기 일반 사본

      1. 업스트림 ixdba.net{
      2. ip_hash
      3. 서버 192.168.12.133:80;
      4. 서버 192.168.12.134:80 다운; max_fails
      5. 3 fail_timeout=20초; 서버 192.168. 12.136:8080; 🎜>upstream은 Nginx의 HTTP 업스트림 모듈입니다. 이 모듈은 간단한 스케줄링 알고리즘을 사용하여 클라이언트 IP에서 백엔드 서버로의 로드 밸런싱을 달성합니다. 위 설정에서 로드 밸런서 ixdba.net의 이름은 upstream 지시문을 통해 지정됩니다. 이 이름은 임의로 지정할 수 있으며 나중에 필요할 때 직접 호출할 수 있습니다. Nginx의 로드 밸런싱 모듈은 현재 4가지 스케줄링 알고리즘을 지원하며, 아래에 소개된 마지막 두 가지 알고리즘은 타사 스케줄링 방법입니다.
      6.  폴링(기본값). 각 요청은 시간순으로 하나씩 다른 백엔드 서버에 할당됩니다. 백엔드 서버가 다운되면 결함이 있는 시스템이 자동으로 제거되어 사용자 액세스에 영향을 미치지 않습니다.
      7. 무게. 폴링 가중치를 지정합니다. 가중치 값이 클수록 액세스 확률이 높아집니다. 각 백엔드 서버의 성능이 고르지 않을 때 주로 사용됩니다.
      ip_hash. 각 요청은 접속된 IP의 해시 결과에 따라 할당되므로 동일한 IP의 방문자는 항상 백엔드 서버에 접속할 수 있으며 이는 동적 웹 페이지의 세션 공유 문제를 효과적으로 해결합니다.
      
       공정합니다. 위의 두 가지보다 더 지능적인 로드 밸런싱 알고리즘입니다. 이 알고리즘은 페이지 크기와 로딩 시간을 기반으로 로드 밸런싱을 지능적으로 수행할 수 있습니다. 즉, 백엔드 서버의 응답 시간을 기반으로 요청을 할당하고 응답 시간이 짧은 요청의 우선 순위를 지정할 수 있습니다. Nginx 자체는 fair를 지원하지 않습니다. 이 스케줄링 알고리즘을 사용해야 하는 경우 Nginx의 upstream_fair 모듈을 다운로드해야 합니다.
       url_hash. 접근한 URL의 해시 결과에 따라 각 URL이 동일한 백엔드 서버로 연결되도록 요청을 분산시키면 백엔드 캐시 서버의 효율성을 더욱 높일 수 있습니다. Nginx 자체는 url_hash를 지원하지 않습니다. 이 예약 알고리즘을 사용해야 하는 경우 Nginx 해시 소프트웨어 패키지를 설치해야 합니다.
      HTTP 업스트림 모듈에서는 server 명령을 통해 백엔드 서버의 IP 주소와 포트를 지정할 수 있으며, 로드 밸런싱 스케줄링에서 각 백엔드 서버의 상태를 설정할 수도 있습니다. 일반적으로 사용되는 상태는 다음과 같습니다.
       down. 이는 현재 서버가 일시적으로 로드 밸런싱에 참여하지 않음을 의미합니다.
       백업, 예약된 백업 머신. 백업이 아닌 다른 모든 머신이 실패하거나 사용 중일 때 백업 머신이 요청되므로 이 머신은 부담이 가장 적습니다.
       max_fails, 허용되는 요청 실패 횟수, 기본값은 1입니다. 최대 횟수를 초과하면 Proxy_next_upstream 모듈에서 정의한 오류가 반환됩니다.
      fail_timeout, max_fails 실패 후 서비스를 일시 중단하는 시간입니다. max_fails는 failure_timeout과 함께 사용할 수 있습니다.
      로드 스케줄링 알고리즘이 ip_hash인 경우 로드 밸런싱 스케줄링에서 백엔드 서버의 상태는 가중치 및 백업이 될 수 없다는 점에 유의하세요. 5.서버 가상 호스트 설정
      다음은 가상 호스트 설정에 대한 설명입니다. 가상 호스트의 구성 내용을 다른 파일에 작성한 후 include 지시어를 통해 포함시키는 것이 유지 관리가 더 쉬워지도록 권장됩니다.
      [html] 보기 일반 사본
      
      서버{
      

      
      듣기 80; server_name 192.168.12.188 www.ixdba.net;
      

      index index.html index.htm index.jsp

      root /web/wwwroot /www.ixdba.net
      1. 문자 집합
      2. 
         서버 플래그는 가상 호스트의 시작을 정의하고, Listen은 가상 호스트의 서비스 포트를 지정하는 데 사용되며, server_name은 IP 주소 또는 도메인 이름을 지정하는 데 사용되며, 여러 도메인 이름은 공백으로 구분됩니다. . Index는 접속을 위한 기본 홈 페이지 주소를 설정하는 데 사용되며, root 명령은 가상 호스트의 웹 페이지 루트 디렉터리를 지정하는 데 사용됩니다. 이 디렉터리는 상대 경로 또는 절대 경로일 수 있습니다. Charset은 웹 페이지의 기본 인코딩 형식을 설정하는 데 사용됩니다.
         access_loglogs/www.ixdba.net.access.log main;
         access_log는 이 가상 호스트의 액세스 로그 저장 경로를 지정하는 데 사용되며, 마지막 main은 액세스 로그의 출력 형식을 지정하는 데 사용됩니다.

         6. URL 일치 구성
         URL 주소 일치는 Nginx 구성에서 가장 유연한 부분입니다. 위치는 정규식 일치 및 조건부 판단 일치를 지원합니다. 사용자는 위치 지시어를 사용하여 동적 및 정적 웹 페이지의 Nginx 필터링을 구현할 수 있습니다.
         다음 설정은 위치 지시어를 통해 웹페이지 URL을 분석하고 처리하는 데 사용됩니다. 확장자가 .gif, .jpg, .jpeg, .png, .bmp 및 .swf로 끝나는 모든 정적 파일은 nginx로 전달됩니다. Expires는 정적 파일의 만료 시간을 지정하는 데 사용되며 여기서는 30일입니다.
         

         [html] 보기 일반 사본

         1. 위치 ~ .*.(gif|jpg|jpeg|png|bmp|swf)$ {
         2. 루트 /web/wwwroot/www.ixdba.net;
         3. 만료
         4. } 
         
         

         다음 설정은 upload 및 html에 있는 모든 파일을 nginx에 넘겨 처리하도록 하는 것입니다. 물론 upload 및 html 디렉터리는 /web/wwwroot/www.ixdba에 포함되어 있습니다. 넷 디렉토리 중간.
          

         [html] 보기 일반 사본

         1. 위치 ~ ^/(upload|html)/ {
         2. 루트 /web/wwwroot/ www.ixdba.net;
         3. 만료 30일 >마지막 설정에서 위치는 이 가상 호스트 아래의 동적 웹 페이지, 즉 다음과 같은 모든 파일에 대한 필터링 프로세스입니다. .jsp 접미사는 처리를 위해 로컬 시스템의 8080 포트로 전달됩니다.
         [html] 보기 일반 사본
         
         

         
         

         위치 ~ .*.jsp$ {
         index index.jsp 🎜>
         1. Proxy_pass http://localhost:8080; }
         3. 7. 🎜>StubStatus 모듈은 마지막 시작 이후 Nginx의 작동 상태를 얻을 수 있습니다. 이 모듈은 핵심 모듈이 아니며 이 기능을 사용하려면 Nginx를 컴파일하고 설치할 때 수동으로 지정해야 합니다.
         4. 다음 명령은 실제로 Nginx 작동 상태를 얻는 기능을 활성화하도록 지정합니다.
          
         
         [html] 보기 일반 사본
         1. 위치 /NginxStatus {
         2. stub_status on
         3. access_log 로그/NginxStatus .log;                                  ../htpasswd;
         4. }
         6. Stub_status가 "로 설정되었습니다. on"을 선택하면 StubStatus의 작업 상태 통계 기능이 활성화됩니다. access_log는 StubStatus 모듈의 액세스 로그 파일을 지정하는 데 사용됩니다. auth_basic은 Nginx의 인증 메커니즘입니다. auth_basic_user_file은 인증을 위한 비밀번호 파일을 지정하는 데 사용됩니다. Nginx의 auth_basic 인증은 Apache와 호환되는 비밀번호 파일을 사용하므로 비밀번호 파일을 생성하려면 Apache의 htpasswd 명령을 사용해야 합니다. 비밀번호 파일을 생성하는 방법은 다음과 같습니다. /usr/local/apache/bin/htpasswd -c /opt/nginx/conf/htpasswd webadmin에는 다음과 같은 프롬프트 메시지가 표시됩니다.
         새 비밀번호:
         비밀번호를 입력하면 시스템에서 비밀번호를 다시 입력하라는 메시지가 표시됩니다. 확인 후 사용자가 성공적으로 추가되었습니다.
         Nginx의 실행 상태를 확인하려면 http://ip/ NginxStatus를 입력한 후 방금 생성한 사용자 이름과 비밀번호를 입력하면 다음 정보를 볼 수 있습니다. 활성 연결: 1

         서버가 처리된 요청을 수락합니다
         393411 393411 393799
         읽기: 0 쓰기: 1 대기: 0
         
         
         활성 연결은 현재 활성화된 연결 수를 나타내며, 세 번째 줄은 Nginx를 나타냅니다. 현재 총 393,411개의 연결이 처리되었고, 393,411개의 핸드셰이크가 성공적으로 생성되었으며, 총 393,799개의 요청이 처리되었습니다. 마지막 줄의 읽기는 Nginx가 읽은 클라이언트 헤더 정보 수를 나타내고, Write는 Nginx가 클라이언트에 반환한 헤더 정보 수를 나타내며, "Waiting"은 Nginx가 처리를 완료하고 기다리고 있는 상주 연결 수를 나타냅니다. 다음 요청 지시.

         
         마지막 설정에서는 가상 호스트의 오류 메시지 반환 페이지가 설정되어 있으며, error_page 명령을 통해 다양한 오류 메시지의 반환 페이지를 사용자 정의할 수 있습니다. 기본적으로 Nginx는 홈 디렉터리의 html 디렉터리에서 지정된 반환 페이지를 검색합니다. 이러한 오류 메시지에 대한 반환 페이지의 크기는 512K를 초과해야 한다는 점에 유의하는 것이 특히 중요합니다. 그렇지 않으면 IE 브라우저의 크기로 대체됩니다. 기본 오류 페이지.
         
         
         
         

         [html] 보기 일반 사본

         
         

         
         

         error_페이지 404 /404.html;
         error_페이지 500 502 503 504 /50x.html;
         1.                                                                                      ~                                 원문은 "Technology Makes Dreams" 블로그(http://ixdba.blog.51cto.com/)를 참조하세요. 2895551/790611
         위 내용은 내용의 측면을 포함하여 Nginx 구성 파일의 구문 분석을 소개합니다. PHP 튜토리얼에 관심이 있는 친구들에게 도움이 되기를 바랍니다.