여러 시스템에 분산로드 밸런싱과 Nginx에 간단한 요청 유통 ----

 

요구 사항 :

http://10.3.10.99:8000에 배포되는 요청
http://10.3.10.22:8089/time_discern
http://10.3.10.99:8089/time_discern

 

 

• Nginx에 실제로 클러스터입니다 : 웹으로 구성된 + 역방향 프록시 + 상류 분배 모듈 호스팅
가상 호스트 : 동의 및 요청에 응답을하는
프록시 리버스 : 데이터를 얻을 수있는 데이터 서버와 함께 사용 가구가
상류 : Nginx에이 데이터를 얻을 수있는 데이터 서버 말할
• 데이터를 ⾛ 위해
사용 사용자 1) 가상 호스트 요청을 받아
2) 리버스 프록시를 찾기 위해 가상 호스트
가자 3) 역방향 프록시를 업스트림
4) 상류에게 ⼀ 데이터 서버 IP의
요청 5) 데이터 및 모양에 Nginx에 서버가 시작 사용 가구
(6) ) 요청 및 서버 데이터 처리 요구 접수
서버 Nginx에 대한 데이터 요청에 응답하여 7)
. 8) 사용자 요청에 응답하여 상기 Nginx에 사용

 

 

 

이 내용, 구성 파일

그것은 세 가지 주요 부분을 포함

(1) 블록 글로벌 : 전체 동작 명령 구성 서버

예를 들어 1 worker_processes, 동시 처리 장치의 수를

(2) 이벤트 블록 : 효과 Nginx의 서버와 사용자의 네트워크 연결

예 worker_connections 1024; 최대 연결 번호 1024 지원

(3) HTTP 블록

           또한 그것은 두 부분을 포함 :

                HTTP 글로벌 블록

                서버 블록

 

nginx.conf

#user 아무도 없다 
1 worker_processes; 

#error_log 로그 /하는 error.log; 
#error_log 로그 /하는 error.log 통지; 
#error_log 로그 /하는 error.log 정보; 

#pid 로그 / nginx.pid; 


이벤트 { 
    worker_connections 1024; 
} 


HTTP { 
    의 mime.types를 포함한다; 
    default_type 애플리케이션 / octet-stream을; 

    메인 #log_format '$ REMOTE_ADDR - $의 REMOTE_USER [$ time_local] "$ 요청' ' 
    #'$ 상태의 body_bytes_sent $"$ HTTP_REFERER " ' 
    #'를"$ HTTP_USER_AGENT ","$ HTTP_X_FORWARDED_FOR " '; 

    #access_log 로그 / access.log의 주요; 

    에 sendfile을; 
    에 #tcp_nopush;


    #gzip 일; 

   ENV 업스트림 { 
   # ip_hash; 
   # 폴링 확률 중량, 중량 및 백엔드 서버 불균일 케이스의 성능에 대한 액세스 속도에 비례 
      서버 10.3.10.22:8089 중량 = 10; 
      서버 10.3.10.99:8089 (10) = 체중; 
    } 

    서버 { 
        (가) 듣고 (80), 
        서버 _ 10.3.10.99, 

        #charset KOI8-R & LT; 

        #access_log 로그 / 주요 host.access.log; 

       # 소재지 / { 
       # proxy_pass HTTP : //를 ENV / time_discern; 
       # 루트 HTML을; 
       index.htm으로 인덱스있는 index.html #; 
       #} 
        
         위치 / { 
                proxy_redirect을 끄고;
                proxy_set_header 호스트 $ 호스트;  
        #
                proxy_set_header X-실시간 IP $ REMOTE_ADDR; 
                proxy_set_header X는-전달-를 들어 $ proxy_add_x_forwarded_for; 

                proxy_pass에 http : // ENV / time_discern; 
        } 

        위치 / time_discern / { 
                proxy_redirect 오프; 
                proxy_set_header 호스트 $ 호스트; 
                proxy_set_header X-실시간 IP $ REMOTE_ADDR; 
                proxy_set_header X는-전달-를 들어 $ proxy_add_x_forwarded_for; 

                proxy_pass에 http : // ENV; 
        } 

        #error_page /404.html을 404; 

        # 정적 페이지 /50x.html에 리디렉션 서버 에러 페이지 
        error_page 500 502 503 504 /50x.html;
        위치 = /50x.html { 
            루트 HTML; 
        } 

        # 프록시 127.0.0.1:80에 아파치 듣기로 PHP 스크립트 
        # 
        #location ~ \ .PHP $ { 
        # proxy_pass http://127.0.0.1; 
        #} 

        #는 127.0.0.1:9000에 FastCGI를 서버 듣기로 PHP 스크립트를 통과 
        # 
        #location ~ \ .PHP $ { 
        # 루트 HTML; 
        # fastcgi_pass 127.0.0.1:9000; 
        # fastcgi_index의 index.php를; 
        # fastcgi_param의 SCRIPT_FILENAME / 스크립트 $ fastcgi_script_name; 
        # fastcgi_params을 포함한다;
        #} 

        아파치의 문서 루트 경우 #은 .htaccess 파일에 대한 액세스를 거부 
        의 nginx의 하나 #의 동의한다 
        # 
        #location ~ /\.ht { 
        # 모두 거부; 
        #} 
    } 


    # IP-의 혼합, 이름 - 및 포트 기반 구성하여 다른 가상 호스트 
    #의 
    #server을 { 
    # 8000을 듣고; 
    # somename 듣고 : 8080; 
    # 서버 _의 somename 별칭 another.alias; 

    # 위치 / { 
    # 루트 HTML; 
    # 인덱스있는 index.html index.htm으로; 
    #} 
    #} 


    # HTTPS 서버 
    #의 
    #server { 
    # 443 SSL을 듣고; 
    # 서버 _ 로컬 호스트;

    # ssl_certificate cert.pem; 
    # ssl_certificate_key의 cert.key; 

    # ssl_session_cache 공유 : SSL : 1m; 
    # ssl_session_timeout 5m; 

    # ssl_ciphers의 HIGH : aNULL :! MD5; 
    # ssl_prefer_server_ciphers에; 

    # 위치 / { 
    # 루트 HTML; 
    # 인덱스있는 index.html index.htm으로; 
    #} 
    #} 

}

 

 

###### 중국어 Nginx의 상세한 구성 파일 nginx.conf ##### 

#DEFINE Nginx의 사용자 및 사용자 그룹을 실행하는 
사용자의 WWW WWW를, 

번호 #nginx 프로세스 추천 설정은 CPU 코어의 총 수와 동일하다. 
8 worker_processes; 
 
# 글로벌 오류 로그 정의 유형, [디버그 | 정보 | 공지 사항 | (가) 경고 | 오류 | 치명타] 
의 error_log /usr/local/nginx/logs/error.log 정보; 

# 과정 PID 파일 
PID / usr / 지방 / nginx를 / 기록 / nginx.pid; 

# 디스크립터를 열 수있는 최대 처리 지정 번호 
# 운전을 연결의 최대 번호를 
# 프로세스가 파일 디스크립터 Nginx의 수를 열어이 지령 수단은, 이론 값은 오픈 파일의 최대 수가 있어야 ( ulimit를 -n)의 nginx 공정 수로 나눈하지만 ulimit를 -n의 값과 일치하여 유지되도록 최선의 nginx 할당 요청은 균일 그렇지 않다. 
# 이제 65535 대응에 작성해야 worker_rlimit_nofile 리눅스 2.6 커널 공개 번호 65535에서 파일을 엽니 다. 
과정에 파견 nginx를 할당 요청이 너무 균형되지 않기 때문에 #이 말은 10240를 입력 그렇다면이며, 총 양은 10240보다가있을 수 있습니다 3-4000000 동시 처리에 도달 한 다음 502 오류를 반환합니다. 
65535 worker_rlimit_nofile; 


이벤트 
{
    # 참조 이벤트 모델, 사용 [kqueue | rtsig | epoll에 | / dev에 / 여론 조사 | 선택 | 설문 조사]는 epoll의 모델을 
    실행하는 경우 # 2.6 이상이 고성능 네트워크에 리눅스 커널이 I / O를 모델, 리눅스는 FreeBSD의에, epoll에 추천 위의 kqueue 모델을 사용합니다. 
    보충 번호 : 
    유사한 아파치와 #, 다른 운영 체제의 nginx, 다른 이벤트 모델 
    #A) 표준 이벤트 모델 
    # 선택, 설문 조사는 현재의 시스템보다 효율적인 방법이 존재하지 않는 경우, nginx를 선택합니다, 표준 이벤트 모델에 속하는 선택하거나 설문 조사 
    #B) 효율적인 이벤트 모델 
    #Kqueue : 4.1의 FreeBSD에서 사용이 2.9+을 오픈 BSD, NetBSD의 2.0 듀얼 프로세서 kqueue 사용을 사용하여 맥 OS X에서 맥 OS X 시스템은 커널 패닉의 원인이 될 수 있습니다. 
    #Epoll : 사용 시스템 리눅스 커널 버전 2.6 이상. 
    #는 / dev / 설문 조사 : 솔라리스 7 11/99 +, HP에서 사용 / UX 11.22+ (eventport), IRIX 6.5.15+ 과의 Tru64 UNIX 5.1A +. 
    #Eventport : 솔라리스 10에서 사용. 문제는 당황 커널 방지하기 위해, 보안 패치를 설치하는 것이 필요하다. 
    epoll 파일의 사용, 

    연결 # 단일 프로세스의 최대 수 (프로세스 번호 * = 접속 연결의 최대 숫자) 
    100 %의 CPU를하지 않는 가능한 대형과 프로세스 하드웨어 조정, 앞면과 함께 작품에 #에 따라,하지만이 여행을 갔다. 이론적으로 허용되는 연결의 프로세스 최대 번호 당 최대 연결 수는 각 서버의 nginx입니다.
    65535 worker_connections; 

    #keepalive 타임 아웃. 
    60 keepalive_timeout, 

    헤드 # 클라이언트 요청 버퍼 크기. 이것은 페이징 시스템의 크기에 따라 설정 될 수 있으며, 일반적인 요청 헤더 크기는 1K를 초과하지 않는,하지만 인해 일반 페이징 시스템에, 그래서 여기에 설정 페이지 크기 1K보다 커야합니다. 
    # 페이지 크기는 제작 된 getconf의 PAGESIZE을 주문할 수 있습니다. 
    # [@ web001 루트 ~] PAGESIZE의 # 된 getconf 
    # 4096 
    # 그러나이 client_header_buffer_size은 4K를 초과하지만,이 값은 "시스템 페이지 크기"정수 배로 설정해야합니다 client_header_buffer_size. 
    4K client_header_buffer_size, 

    많은 시간이 요구되지 후이 지정된 파일 캐시가 열립니다 #은 기본적으로 사용할 수 없습니다, 최대 버퍼, 권고의 수를 지정하고 파일 같은 수의 열, 삭제 캐시 파일을 비활성화 말합니다. 
    최대 = 65535 = 비활성 open_file_cache의 60; 

    #이 정보가 유효한 체크 캐시입니다 시간을 의미합니다.
    # 구문 : open_file_cache_valid 시간 기본값 : open_file_cache_valid 60 사용 분야 : HTTP, 서버, 위치이 지시어를 지정 유효한 open_file_cache 캐시 항목을 확인하는 데 필요한 정보를 제공합니다. 
    open_file_cache_valid 80;

    파일이 시간 비활성 내에 사용되지 않은 경우,이 수를 초과하는 경우 최소한의 비활성 시간 #open_file_cache 명령 파라미터 파일 번호의 제공, 파일 디스크립터 캐시에 개방되어, 상술 한 예는, 그것 것 제거. 
    # 구문 : open_file_cache_min_uses 번호 기본값 : open_file_cache_min_uses 1 개 사용 필드 : HTTP, 서버, 위치이 지시어를 지정하면 더 큰 값을 사용하는 경우, 특정 시간 프레임 내에서 사용할 수 있습니다 open_file_cache 잘못된 명령 매개 변수에있는 파일의 최소 번호, 파일 설명 캐시의 문자는 항상 열려 있습니다. 
    open_file_cache_min_uses 1, 
    
    # 구문 :에 open_file_cache_errors | 기본값 해제 : 필드 개시 open_file_cache_errors :. HTTP 서버, 위치 파일이 검색 캐시 오류에 기록되어 있는지 여부를이 지시어를 지정 
    open_file_cache_errors을 켜기; 
} 
 
 
 
# HTTP 서버 설정, 그것의 역방향 프록시 기능을 사용하여로드 밸런싱 지원을 제공 
HTTP 
{ 
    에 대한 # 파일 확장자 및 파일 형식을지도 
    하며이의 mime.types을 포함 
    #charset UTF-을 8;

    # 기본 파일 형식 
    default_type 파일 응용 프로그램 / octet-stream을, 

    # 기본 인코딩 

    # 서버 이름 해시 테이블 크기 
    제어 명령 및 server_names_hash_bucket_size server_names_hash_max_size 저장 # 서버 이름 해시 테이블. 매개 변수 해시 버킷의 크기는 항상 해시 테이블의 크기 및 프로세서의 여러 방법으로 캐시 크기와 동일합니다. 프로세서에서 가속 키 해쉬 테이블 조회 후 메모리 액세스의 수를 줄이는 것이 가능해진다. 해시 버킷 크기가 프로세서 캐시의 크기에 모든 방법과 동일한 경우, 키, 메모리 2 배 최악의 경우의 조회 수를 찾을 수 있습니다. 첫 번째는 어드레스 저장 수단을 결정하고, 두 번째는 저장 유닛의 키를 찾는 것이다. . Nginx의 메시지 해시 최대 크기 또는 해시 버킷 크기를 증가시키기 위해 필요에 따라서, 지정된 후 이전의 크기는 기본 매개 변수가 1 씩 증가 
    ; Server_names_hash_bucket_size 128 

    헤드 # 클라이언트 요청 버퍼 크기. 이것은 페이징 시스템의 크기에 따라 설정 될 수 있으며, 일반적인 요청 헤더 크기는 1K를 초과하지 않는,하지만 인해 일반 페이징 시스템에, 그래서 여기에 설정 페이지 크기 1K보다 커야합니다. PAGESIZE 만든 된 getconf 페이지 크기를 주문할 수 있습니다. 
    32K의 client_header_buffer_size; 

    # 클라이언트 요청 헤더 버퍼 크기. nginx를 헤더가 너무 큰 경우, 그것은 읽을 large_client_header_buffers를 사용, 헤더 값을 읽을 수있는 기본 client_header_buffer_size이 버퍼를 사용합니다. 
    64K를 large_client_header_buffers 4]. 

    업로드 된 파일의 크기에 의해 # Nginx의 세트 
    client_max_body_size 800 단계;

    # 열기 효율적인 파일 전송, 응용 프로그램이 디스크 IO 무거운 의무 응용 프로그램을 다운로드에 사용되는 경우에 일반적인 응용 프로그램에 대한 출력 파일을 sendfile 함수 호출은, 디스크 및 네트워크 I 균형을 위해, 오프로 설정 될 수 있는지 여부를 nginx를 sendfile을 명령 지정 / O 처리 속도와 시스템의 부하를 감소시킨다. 참고 : 사진이 제대로이 떨어져 넣어 표시되지 않는 경우. 
    지시어를 지정 #sendfile 일반적인 응용 프로그램에 대한 출력 파일의 nginx sendfile을 호출 기능 (제로 카피 모드)인지, 그것은에 설정해야합니다. 디스크 IO 중장비 애플리케이션을 다운로드하기 위해 사용되는 애플리케이션이이 오프로 설정 될 수 있으면 IO 네트워크와 디스크의 처리 속도의 균형을 위해, 시스템의 가동 시간을 감소시킨다. 
    ON sendfile을; 

    # 오픈 액세스의 디렉토리 목록은 기본적으로 해제, 해당 서버를 다운로드합니다. 
    자동 색인 ON; 

    #이 옵션은 sendfile을 사용하는 경우이 옵션은 사용 활성화 또는 TCP_CORK socke 옵션을 사용 불가능 
    , ON tcp_nopush 
     
    TCP_NODELAY ON; 

    # 더 이상 연결 시간 (초)은 
    120 keepalive_timeout, 

    #FastCGI 관련 파라미터를 개선하기 위해 웹 사이트 성능 : 자원 소비 감소, 액세스 속도를 향상시킬 수 있습니다. 다음 매개 변수는 문자 그대로 이해하고 볼 수 있습니다. 
    300 fastcgi_connect_timeout; 
    fastcgi_buffer_size 64K; 
    fastcgi_buffers 4 64K.; 
    fastcgi_send_timeout 300;
    300 fastcgi_read_timeout; 
    fastcgi_busy_buffers_size 128K; 
    fastcgi_temp_file_write_size 128K; 

    #gzip 모듈 배치 
    GZIP에서 # 오픈 GZIP 압축 출력 
    gzip_min_length 1K # 최소 압축 파일 크기 
    gzip_buffers 4 16K # 감압 버퍼 
    gzip_http_version 1.0 # 압축 된 버전 (1.1 기본적 선단부 경우 squid2.5 사용 1.0) 
    gzip_comp_level 2 # 압축 수준은 
    텍스트 / 일반 응용 프로그램 / x 축 gzip_types 자바 스크립트 텍스트 / CSS는 응용 프로그램 / XML을 #의 압축 방식이, 다음이 쓰기에 필요가 없습니다, 이미 포함 textml 기본, 또한 최대 쓰기 아무 문제가 없다, 그러나이 경고가있을 것입니다. 
    ON gzip_vary, 

    사용에 IP 연결의 수는 필요 # 턴 제한 
    #limit_zone 콘텐츠 크롤러 $의 binary_remote_addr가 10m이며, 



    구성의 균형 # 부하 
    상류 piao.jd.com { 
     
        부하 #upstream의 균형을, 무게는 무게, 무게는 시스템 구성에 따라 정의 할 수 있습니다. 높을수록 기회 weigth 파라미터는 중량 가중치가 할당된다. 
        . 서버 192.168.80.121:80 무게 = 3; 
        서버 192.168.80.122:80 무게 = 2 ;
        중량 = 3 192.168.80.123:80 서버]. 

        네 할당 #nginx 상류 현재 실시 지지체 
        # 1, 폴링 (기본) 
        # 각각 다른 시간 순서 백엔드 서버에 할당 된 각 요청하는 경우 백엔드 서버 다운 오프 자동으로 제거. 
        # 2 중량 
        폴링 무게 #의 확률 및 케이스 요철 백엔드 서버 성능에 대한 액세스의 비율에 비례한다. 
        # 예 : 
        #upstream의 bakend { 
        # 서버 192.168.0.14 중량 = 10; 
        # 서버 192.168.0.15 중량 = 10, 
        #} 
        # 2 ip_hash 
        는 IP 접속에 의해 할당 된 각 요청 # 해시 결과, 고정 너무 각 게스트 액세스 백 엔드 서버, 당신은 세션의 문제를 해결할 수 있습니다. 
        # 예를 들어 : 
        #upstream의 bakend { 
        # ip_hash; 
        # 서버 192.168.0.14:88;  
        # 서버 192.168.0.15:80;
        #} 
        . # 3, 공정 (제 3 자) 
        # 백엔드 서버 할당 요청, 짧은 응답 시간을 우선 할당의 반응 시간으로하는 방법. 
        {백엔드 #upstream 
        # 서버 서버 1, 
        # 서버 서버 2, 
        # 공정; 
        #} 
        . # 4, url_hash (제 3 자) 
        액세스 URL 할당 요청, 같은 백엔드 서버로 각 URL, 백엔드에 #을 눌러 해시 결과 서버 때 캐시 더 효과적입니다. 
        예 번호 : 해시 상류에 문을 가입, 서버의 문은 무게와 같은 다른 매개 변수를 쓸 수없는, hash_method 해시 알고리즘이 사용됩니다 
        #upstream 백엔드 { 
        # 서버 squid1 : 3128; 
        # 서버 squid2 : 3128; 
        # $ REQUEST_URI 해시; 
        # CRC32가 hash_method, 
        #} 

        #tips을 : 
        IP 및 기기 상태 #upstream의 bakend는 {# 장치 {로드 밸런싱 정의} 
        # ip_hash 단계; 
        # 서버 127.0.0.1:9090 아래로; 
        # = 2 중량 127.0.0.1:8080 서버; 
        # 서버 127.0.0.1:6060; 
        # 127.0.0.1:7070 백업 서버; 
        #} 
        사용할 필요가 균형 서버 부하 #의 proxy_pass 증가 HTTP : // bakend / 

        각 디바이스의 상태가 #에 설정된 
        임시 부하에 참여하지 않는 전면 단일 서버 1.down # 
        큰 중량, 큰 중량의 중량 하중의 # 2.weight. 
        # 3.max_fails가 : 실패한 요청의 수 1. 최대 주파수 오류가 proxy_next_upstream 모듈 정의 반환 초과하는 경우 기본을 허용 
        , max_fails 실패 후 일시 정지 시간을 : #의 4.fail_timeout합니다. 
        # 5.backup : 다른 모든 비 백업 시스템 다운이나 바쁜, 백업 시스템을 요청합니다. 이 기계는 가벼운 압력이 될 것입니다 그래서. 

        #nginx 사용하여 서버에 사용하지 않는 설정, 여러 세트의 균형을 동시에 부하를 지원합니다. 
        #client_body_in_file_only 디버그에 사용되는 파일에 데이터를 통해 클라이언트 게시물을 말할 수 On으로 설정
        #client_body_temp_path 디렉토리의 로그 파일이 세 개의 층 카탈로그로 설정할 수 있습니다 설정 
        URL을 매칭 리디렉션 할 수 있습니다 #location 또는 균형 새로운 프록시 부하 
    } 
     
     
     
    구성 # 가상 호스트
    서버 
    { 
        # 청취 포트 
        듣고 80; 

        # 공백으로 구분하여 여러 도메인 이름을 가질 수 있습니다 
        서버 _ www.jd.com jd.com, 
        인덱스의 index.php index.html을 index.htm으로를, 
        루트 / 데이터 / WWW / JD를, 

        한국인을 ******로드 밸런싱 
        ? LOCATION ~ * (PHP | PHP5) $ .. 
        { 
            fastcgi_pass 127.0.0.1:9000, 
            fastcgi_index의 index.php를, 
            (가) fastcgi.conf 포함; 
        } 
         
        # 사진 캐시 시간 
        위치 ~ * .. (GIF | JPG |이 JPEG | PNG가 | BMP | SWF)가 $  
        {
            (가) 10D 만료는; 
        } 
         
        CSS 캐싱 및 시간 설정 #js 
        (JS | CSS) LOCATION ~ *을 $ ..? 
        { 
            IH 만료; 
        } 
         
        # 로그 포맷 
        클라이언트의 IP 주소를 기록 # $ REMOTE_ADDR 및 $ HTTP_X_FORWARDED_FOR를; 
        # $으로의 REMOTE_USER를 : 사용자 이름을 저장하는 데 사용되는 클라이언트; 
        # $ time_local : 액세스 시간 및 시간대를 기록하는 데 사용; 
        # $으로 요청 : HTTP와 URL이 프로토콜이 기록 요청에 사용됩니다 
        # $으로 상태 : 요청의 상태를 기록하는 데 사용; 성공은 200입니다 
        # $ body_bytes_sent : 레코드가 클라이언트의 주요 콘텐츠 파일 크기로 전송됩니다; 
        # $ HTTP_REFERER : 이상 해당 페이지에서 액세스 링크를 기록하는 데 사용; 
        # $ HTTP_USER_AGENT : 클라이언트 브라우저에 대한 정보를 기록, 
        당신은 고객의 IP 주소를 얻을 수 있도록 # 일반적으로, 뒷면에 프록시 웹 서버를 리버스 $에 의해 remote_add 역방향 프록시 서버의 IP 주소의 IP 주소를 얻는다. 프록시 서버에게 전달 요청 HTTP 헤더 정보를 역방향, 당신은 서버 주소 기존 고객 및 이전 클라이언트의 IP 주소를 기록하는 정보 요청 x_forwarded_for 증가시킬 수있다.
        액세스 log_format 'REMOTE_ADDR $ - $ REMOTE_USER [$ time_local] "$ 요청"' 
        '$ $ body_bytes_sent 상태 "$ HTTP_REFERER' ' 
        '"$ HTTP_USER_AGENT "$ HTTP_X_FORWARDED_FOR '; 
         
        # 가상 호스트 액세스 로그의 정의 
        ACCESS_LOG /usr/local/nginx/logs/host.access.log 메인;
        ACCESS_LOG /usr/local/nginx/logs/host.access을. log404 404.log, 
         
        "/"에 # 리버스 프록시 가능 
        위치 / { 
            proxy_pass는 http://127.0.0.1:88, 
            proxy_redirect의 OFF, 
            proxy_set_header는 X-실시간 IP - $ REMOTE_ADDR; 
             
            을 통해 # 백 엔드 웹 서버 X는-전달 용 - 사용자의 실제 IP 얻을 수 
            있는 X가 - 전달 - 더 For- $ proxy_add_x_forwarded_for proxy_set_header를, 
             
            여기에 #이 옵션 일부 역방향 프록시 구성이다. 
            proxy_set_header 호스트 $ 호스트;

            client_max_body_size 1,000; 

            클라이언트 프록시 캐시 # 요청한 버퍼의 바이트의 최대 번호 
            가 덜 256K 이미지보다 제출 여부에 관계없이 폭스 IE 브라우저, 그리고, 예를 256K에 대해, 비교적 큰 값으로 설정되어 있으면 # 정상. 이 명령에 대한 의견은, 8K 또는 16K 두 번 운영 시스템 페이지 크기 설정이 client_body_buffer_size 기본값을 사용하는 경우 문제가 발생한다. 
            , 200K 사진, 수익 500 내부 서버 오류 오류에 대해, 비교적 큰 제출 # 사용 firefox4.0 또는 IE8.0에 있는지 
            client_body_buffer_size 128K; 

            #은 nginx를 400 이상 응답의 응답 코드 HTTP를 방지 나타냅니다. 
            에 proxy_intercept_errors, 

            타임 아웃 # 백엔드 서버 연결 _ 응답을 기다리는 시간이 초과 악수를 시작 
            백엔드 서버 시간 제한과 #nginx 연결 (프록시 연결 시간 초과) 
            ; proxy_connect_timeout 90 

            # 백엔드 서버 데이터 반환 시간 (제한 시간을 보내기) 
            # 후 엔드 서버 데이터 _ 복귀 시간이 모든 데이터해야 후에 통해 백엔드 서버의 소정의 시간 내에 
            90 proxy_send_timeout, 

            성공적인 접속, 백엔드 서버 응답 시간 (수신 시간 제한 제) 후 #을 
            # 성공적인 연결 백엔드 서버 응답 대기 _ 시간 _ 사실 (또한 상기 요청을 처리하는 백 엔드 서버라고 말할 수있다) 백 - 엔드 프로세싱을 대기 큐에 진입 
            90 proxy_read_timeout; 

            # 사용자 버퍼 크기의 헤더 정보를 저장하기위한 프록시 서버 (Nginx에)를 설정
            # 세트가 버퍼로부터 상기 제 1 부분의 크기가 일반적으로 반응의 응답 헤더의 일부를 포함 응답 프록시 서버를 판독하고,이 값이 경우에 대한 기본 크기이다 명령 지정된 크기 proxy_buffers 버퍼, 그러나, 작게 설정 될 수있다 
            proxy_buffer_size 4K, 

            #proxy_buffers이 평균 다음이 제공 32K 페이지 버퍼 
            또한 기본 페이지 크기 (프록시 서버) 읽기 응답 번호 설정 및 버퍼 크기의 수를, 오퍼레이팅 시스템은 다를 수 또는 4K, 8K있다 
            proxy_buffers 32K 4]. 

            # 고부하 버퍼 크기 (proxy_buffers * 2) 
            proxy_busy_buffers_size 64K; 

            # proxy_temp_path, 데이터 기록 크기로 제공되는 파일 전송이 너무 긴 경우 작업자 프로세스를 방지 차단 
            # 상류 서버로부터의 전송이 값보다 세트 캐시 폴더 사이즈보다, 
            proxy_temp_file_write_size 64K; 
        } 
         
         
        # 체크 Nginx의 상태 설정 어드레스 
        LOCATION / NginxStatus { 
            stub_status ON; 
            ACCESS_LOG ON;
            auth_basic "NginxStatus"; 
        {
            auth_basic_user_file는 confpasswd, 
            내용 #htpasswd의 htpasswd가 파일이 아파치를 생성하는 도구를 제공 할 수 있습니다. 
        } 
         
        # 정적 및 동적 분리 역방향 프록시 구성 지역 
        # 모든 JSP 페이지는 바람둥이 또는 수지 처리에 인계했다 
        .? {$ ~ (| |하여 jspx 할 JSP) 장소 
            ; Proxy_set_header $ 호스트 호스트 
            proxy_set_header는 X-실시간 IP - $ REMOTE_ADDR; 
            proxy_set_header X 축 $ proxy_add_x_forwarded_for를 들어 - 전달, 
            proxy_pass http://127.0.0.1:8080; 
        } 
         
        # 모든 정적 파일이 바람둥이 또는 수지를 거치지 않고 직접 읽을 Nginx에 
        LOCATION ~ * (HTM | HTML | GIF | JPG | JPEG | PNG .. | BMP | SWF | IOC | RAR | ZIP | TXT | FLV | MID | DOC | PPT | 
        PDF | XLS | MP3 | WMA)는 $ 
        }
            15D 만료, 
         
        LOCATION ~ * (JS | CSS) $ ..? 
        { 
            (가) 1H 만료; 
        } 
    } 
} 
###### Nginx의 구성 파일 nginx.conf ##### 중국어 상세