블로그 이미지
OSSW(Open Source System SoftWare

calendar

        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30  

Notice

사이트상에 있는 정적인 파일들에 대해서 어느 특정 사용자가 대역폭을 차지하고 있을 수 있는데,

다음과 같은 방법을 사용하여 네트워크 대역폭의 제한을 설정 할 수 있습니다.



server {

    server_name www.example1.com;

    location /download/ {

        //  모든 사용자에 대해 /download 디렉토리의 파일 다운로드 속도를 10k 로 제한 

        limit_rate 10k;    

        root /var/www.www.example1.com/download/;

    }

    ...

}

 



by hyenas (11월)

'1. 미들웨어이야기 > 04. Nginx' 카테고리의 다른 글

Nginx 대역폭(전송속도) 제한  (0) 2014.11.26
Nginx IP 접근제어 설정  (0) 2014.11.26
Nginx 로그 로테이션 설정  (0) 2014.11.26
Nginx 가상 호스트별 로그 설정  (0) 2014.11.26
Nginx 다중 로그 설정  (0) 2014.11.26
Nginx 로그 설정  (0) 2014.11.26
posted by lovelywas

이번 강의에서는 Nginx IP접근제어에 대해서 알아보겠습니다.



server {

    listen 80;

    server_name www.example1.com;

    location / {

        deny 192.168.56.101

        allow 192.168.56.0/24;

        deny all;

    }

...

}



위에서 부터 차례대로 192.168.56.101의 IP에 대해서 접근을 거부한 다음 192.168.1.0/24 의 접근을 허용하는 설정이며, 마지막에 있는 deny all 지시어는 그 외의 모든 IP주소에 대해 접근거부하는 설정입니다.


접근이 거부된 사용자가 접속시 "403 Forbiden" 페이지로 전환이 됩니다.



by hyenas(11월)

'1. 미들웨어이야기 > 04. Nginx' 카테고리의 다른 글

Nginx 대역폭(전송속도) 제한  (0) 2014.11.26
Nginx IP 접근제어 설정  (0) 2014.11.26
Nginx 로그 로테이션 설정  (0) 2014.11.26
Nginx 가상 호스트별 로그 설정  (0) 2014.11.26
Nginx 다중 로그 설정  (0) 2014.11.26
Nginx 로그 설정  (0) 2014.11.26
posted by lovelywas

이번 강의에서는 로그 rotate 설정에 대해서 알아보도록 하겠습니다.


logrotate.conf 파일에 다음 환경설정을 추가합니다.


 /var/log/nginx/*.log {

    daily

    missingok

    rotate 52

    compress    // 로그 파일에 대한 압축

    delaycompress

    notifempty

    create 640 root adm    // 보관이 되는 파일의 권한 설정

    sharedscripts

    postrotate

    [ ! -f /var/run/nginx.pid ] || kill -USR1 `cat /var/run/nginx.pid`

    endscript

}


기존의 로그파일을 새로운 파일명으로 바꾸고 압축을 합니다.

방금 이름을 바꾼 로그 파일을 닫고 새로운 로그 파일에 기록을 하도록

엔진엑스 마스터 프로세스에 USR1 시그널을 보냅니다.



테스트 방법  :  logrotate -d /nginx/logrotate.conf

응용 : crontab에 설정하여 매일 정시에 로그를 로테이트하여 사용이 가능합니다.



by hyeons(10월)

'1. 미들웨어이야기 > 04. Nginx' 카테고리의 다른 글

Nginx 대역폭(전송속도) 제한  (0) 2014.11.26
Nginx IP 접근제어 설정  (0) 2014.11.26
Nginx 로그 로테이션 설정  (0) 2014.11.26
Nginx 가상 호스트별 로그 설정  (0) 2014.11.26
Nginx 다중 로그 설정  (0) 2014.11.26
Nginx 로그 설정  (0) 2014.11.26
posted by lovelywas

가상 호스트에 각각 로그를 설정하는 예제 입니다.


 

 http {

    ...

    server {

        listen 80;

        server_name www.example1.com ;

        access_log /var/log/nginx/example1.access.log;

        error_log /var/log/nginx/example1.error.log;

        ...

    }

    server {

        listen 80;

        server_name www.example2.com ;

        access_log /var/log/nginx/example2.access.log;

        error_log /var/log/nginx/example2.error.log;

        ...

    }

    server {

        listen 80;

        server_name www.exampl3.com;

        access_log /var/log/nginx/example3.access.log main;

        error_log /var/log/nginx/example3.error.log error_main;

        ...

    }




by hyeons(10월)

'1. 미들웨어이야기 > 04. Nginx' 카테고리의 다른 글

Nginx IP 접근제어 설정  (0) 2014.11.26
Nginx 로그 로테이션 설정  (0) 2014.11.26
Nginx 가상 호스트별 로그 설정  (0) 2014.11.26
Nginx 다중 로그 설정  (0) 2014.11.26
Nginx 로그 설정  (0) 2014.11.26
Nginx와 OpenSSL 보완 취약점  (0) 2014.07.31
posted by lovelywas

동적인 요청에 대한 로그는 main로그 포멧을 사용하고, 정적인 요청은 static_main 로그 포멧을 사용,

에러로그는 error_main 로그포멧을 사용하는 예로 다음과 같이 설정이 가능합니다.


 

http {

    log_format main '$remote_addr - $remote_user [$time_local] ' 

                        '"$request" $status $body_bytes_sent "$http_referer" '

                        '"$http_user_agent" "$http_x_forwarded_for"';


    #정적(static) 파일에 대해서는 다음과 같은 로그 포멧 사용

    log_format static_main '$remote_addr [$time_local] '

                               '"$request" $status $body_bytes_sent

                               '"$http_user_agent";


    #에러 로그에 대해서는 다음과 같은 로그 포멧 사용

    log_format error_main '$remote_addr - $remote_user [$time_local] '

                              '"$request" $status "$http_user_agent";

 ...


 server {

    listen 80;

    server_name example1.com;

    error_log var/log/nginx/example1_error.log error_main;

    location / {

        ...

        access_log /var/log/nginx/example1_main.log main;

    }

    location /static/ {

        ...

        access_log /var/log/nginx/example1_static.log static_main;

    }

}




by hyeons(9월)

'1. 미들웨어이야기 > 04. Nginx' 카테고리의 다른 글

Nginx 로그 로테이션 설정  (0) 2014.11.26
Nginx 가상 호스트별 로그 설정  (0) 2014.11.26
Nginx 다중 로그 설정  (0) 2014.11.26
Nginx 로그 설정  (0) 2014.11.26
Nginx와 OpenSSL 보완 취약점  (0) 2014.07.31
Nginx 실시간 모니터링 (ngxtop)  (0) 2014.07.30
posted by lovelywas

1. Nginx의 로그 포멧은 다음과 같이 설정할 수 있습니다.

 

http {

    log_format combiled '$remote_addr - $remote_user [$time_local] ' 

        '"$request" $status $body_byte_sent ' '"$http_referer" "$http_user_agent"';

    access_log /var/log/nginx/access.log combined;     //combine 형태의 로그

    error_log /var/log/nginx/error.log crit;              //crit 형태의 로그

...




Nginx 로그 레벨 설정

에러 레벨 

의미 

 Alert

 긴급 상황

 Crit

 위험한 상황

 Error

 오류 상황

 Warn

 경고 상황

 Notice

 정상이지만 중요한 상황

 Info

 정보 메시지

 Debug

 디버그레벨 메시지



2. Apache 포맷으로 로그 기록하기

대부분의 웹 로그 분석기는 Apache 로그 포멧을 기준으로 작동을 합니다. 필요에 따라서 NginX의 로그를 다음과 같은 방법을 통하여 Apache 로그 포멧으로 기록을 할 수 있습니다.



log_format main '$remote_addr - $remote_user [$time_local] ' '"$request" $status $body_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded+for"';

access_log /var/log/nginx/access.log main; 



Apache와 Nginx 로그 설정 비교.

 Apache 설정

 Nginx 설정

 의미

 %h

 $remote_addr

 이 사이트에 접근하고 있는 클라이언트들의 IP 주소

 %l

 $remote_user

 사용자가 HTTP 인증으로 로그인했을 때 사용자명

 %t

 $time_local

 요청이 발생한 때 서버의 지역 타임스탬프

 %r

 $request

 서버에 제출된 요청

 %s

 $status

 HTTP 응답 코드 (200, 404, 500 등)

 %b

 $body_bytes_sent

 서버가 클라이언트로 전송한 응답의 크기

 %U

 $http_referer

 클라이언트를 이 서버로 오게 만든 이전 페이지의 URL

 "%{User-agent}i"

 $http_user_agent

 HTTP 요청에 사용된 브라우저 타입


참고 : http://httpd.apache.org/docs/2.2/ko/mod/mod_log_config.html



by hyeons(9월)



posted by lovelywas


2014년 4월 8일 에는 OpenSSL HeartBleed(CVE-2014-0160)버그 인해 긴급하게 OpenSSL버전을 최신버전으로 업그레이드를 하였었는데, 이후에 6월 5일 추가적인 보안 이슈가 생겨서 다시 긴급하게 OpenSSL버전을 업그레이드 하였습니다.



1. 권장하는 openSSL 버전

    OpenSSL 0.9.8 SSL/TLS -> 0.9.8za

    OpenSSL 1.0.0 SSL/TLS -> 1.0.0m

    OpenSSL 1.0.1 SSL/TLS -> 1.0.1h



2. OpenSSL버전 확인하는 방법

   1) 'openssl version' 명령어를 사용 (적합하지 않음)
       다양한 버전의 openssl이 설치가 되어 있을 경우 버전을 명확하게 확인을 할 수가 없습니다.

   2) Nginx가 사용하는 library 확인
      $ ldd `which nginx` | grep ssl
      libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f82e62bf000)
      $ strings /lib/x86_64-linux-gnu/libssl.so.1.0.0 | grep "^OpenSSL "
     OpenSSL 1.0.1f 6 Jan 2014

    3) Nginx Configuration 확인
      nginx 설치할때의 configuration 옵션을 확인하여 참조하고 있는 OpenSSL의 위치를 확인 할 수 있습니다.
     $ ./objs/nginx -V
     nginx version: nginx/1.7.1

     built by gcc 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)

     configure arguments: --with-cc-opt=-I../openssl-1.0.1f/include 
       --with-ld-opt='-L../openssl-1.0.1f -Wl,-Bstatic -lssl -lcrypto -Wl,-Bdynamic -ldl' 
       --with-openssl=../openssl-1.0.1f

참고 URL : http://nginx.com/blog/nginx-05-june-2014-openssl-security-advisory/

6월 5일 추가된 보안 취약점 리스트

DTLS recursion flaw (CVE-2014-0221)

====================================


By sending an invalid DTLS handshake to an OpenSSL DTLS client the code

can be made to recurse eventually crashing in a DoS attack.


Only applications using OpenSSL as a DTLS client are affected.


OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za

OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m.

OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h.


Thanks to Imre Rad (Search-Lab Ltd.) for discovering this issue.  This

issue was reported to OpenSSL on 9th May 2014.


The fix was developed by Stephen Henson of the OpenSSL core team.


DTLS invalid fragment vulnerability (CVE-2014-0195)

====================================================


A buffer overrun attack can be triggered by sending invalid DTLS fragments

to an OpenSSL DTLS client or server. This is potentially exploitable to

run arbitrary code on a vulnerable client or server.


Only applications using OpenSSL as a DTLS client or server affected.


OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za

OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m.

OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h.


Thanks to Jüri Aedla for reporting this issue.  This issue was

reported to OpenSSL on 23rd April 2014 via HP ZDI.


The fix was developed by Stephen Henson of the OpenSSL core team.


SSL_MODE_RELEASE_BUFFERS NULL pointer dereference (CVE-2014-0198)

=================================================================


A flaw in the do_ssl3_write function can allow remote attackers to

cause a denial of service via a NULL pointer dereference.  This flaw

only affects OpenSSL 1.0.0 and 1.0.1 where SSL_MODE_RELEASE_BUFFERS is

enabled, which is not the default and not common.


OpenSSL 1.0.0 users should upgrade to 1.0.0m.

OpenSSL 1.0.1 users should upgrade to 1.0.1h.


This issue was reported in public.  The fix was developed by

Matt Caswell of the OpenSSL development team.


SSL_MODE_RELEASE_BUFFERS session injection or denial of service (CVE-2010-5298)

===============================================================================

 

A race condition in the ssl3_read_bytes function can allow remote

attackers to inject data across sessions or cause a denial of service.

This flaw only affects multithreaded applications using OpenSSL 1.0.0

and 1.0.1, where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the

default and not common.


OpenSSL 1.0.0 users should upgrade to 1.0.0m.

OpenSSL 1.0.1 users should upgrade to 1.0.1h.


This issue was reported in public.  


Anonymous ECDH denial of service (CVE-2014-3470)

================================================


OpenSSL TLS clients enabling anonymous ECDH ciphersuites are subject to a

denial of service attack.


OpenSSL 0.9.8 users should upgrade to 0.9.8za

OpenSSL 1.0.0 users should upgrade to 1.0.0m.

OpenSSL 1.0.1 users should upgrade to 1.0.1h.


Thanks to Felix Gröbert and Ivan Fratrić at Google for discovering this

issue.  This issue was reported to OpenSSL on 28th May 2014.


The fix was developed by Stephen Henson of the OpenSSL core team.


Other issues

============


OpenSSL 1.0.0m and OpenSSL 0.9.8za also contain a fix for

CVE-2014-0076: Fix for the attack described in the paper "Recovering

OpenSSL ECDSA Nonces Using the FLUSH+RELOAD Cache Side-channel Attack"

Reported by Yuval Yarom and Naomi Benger.  This issue was previously

fixed in OpenSSL 1.0.1g.



by. 김현수(8월)


posted by lovelywas


Apache 는 mod_status모듈을 사용하여 /server-status를 사용을 하여 실시간으로 모니터링을 할 수 있는데, nginx는 시스템 자원을 모니터링하는 top과 같이 Nginx의 access로그를 파싱하여 실시간으로 모니터링이 가능합니다.


1. ngxtop 설치 이미지 다운로드

    wget https://github.com/lebinh/ngxtop/archive/master.zip


2. ngxtop 설치

    pip install ngxtop


3. ngxtop 실행(기본화면)


4. top client ip 확인


5. 특정 응답코드 확인


6. remote에 있는 access로그 모니터링 방법

ssh를 사용해서 tail을 걸은다음 모니터링이 가능합니다. 정말 유용한 기능인것 같습니다.


참고 URL : https://github.com/lebinh/ngxtop



by. 김현수(8월)





   



posted by lovelywas

 

NGINX 에서 서드파티 모듈을 설치하기 위해서는 NGIX를 compile시 --add-module 지시어를 사용을 하는데,

다수의 서드파티 모듈들을 지정을 하기 위해서는 각각의 모듈에 대해서 --add-module 을 사용을 해야 합니다.

 

예제)

1. NGINX 부하분산 모듈(nginx-upstream-fair)
    wget https://github.com/gnosek/nginx-upstream-fair/archive/master.zip


2. NGIX AJP모듈(nginx_ajp_module)
    wget https://github.com/yaoweibin/nginx_ajp_module/archive/master.zip

 

 

위의 두가지 서드파티 모듈에 대해서 다음과 같이 옵션을 주고 compile을 할 수 있습니다.

# cd /nginx/src/nginx-1.6.0
# patch -p1 < /nginx/src/nginx_ajp_module-master/ajp.patch
# ./configure --with-debug --prefix=/nginx/nginx-1.6 --with-http_ssl_module

    --with-http_realip_module --with-http_stub_status_module

    --add-module=/nginx/src/nginx_ajp_module-master

    --add-module=/nginx/src/gnosek-nginx-upstream-fair-a18b409

# make

# make install

 

 

by. 김현수(7월)

posted by lovelywas

다수의 upstream 서버를 사용하여 라운드로빈 기능은 구현이 가능하나, 이 upstream 서버들간의 부하를 적절게 설정을 하기 위해서는 다음과 같은 방법을 통한 부하분산(load balancing) 설정이 필요합니다.

 

부하분산을 위해서는 'upstream fair module' 이라는 서드파티 모듈의 설치가 필요합니다.

upstream fair module은 라운드로빈 방식으로 비교적 한가한 서버를 체크하여 그 서버에게 서비스를 요청을 합니다.

 

1. 모듈을 다운로드 합니다.

    wget http://github.com/gnosek/nginx-upstream-fair/tarball/master

 

 2. 엔진엑스를 새 모듈과 함께 컴파일을 합니다.

    tar xvzf ./master

    cd /nginx/src/nginx-1.6.0

 

    #아래의 configuration명령어는 한줄로 입력을 합니다.

    ./configure --with-debug --prefix=/nginx/nginx-1.6 --with-http_ssl_module

     --with-http_realip_module --with-http_stub_status_module

     --add-module=/nginx/src/gnosek-nginx-upstream-fair-a18b409

 

     make

     make install

 

 3. 다음의 설정을 nginx.conf 파일에 추가를 합니다.

 upstream backend {
    server ktds.com:8080;

    server ktds.com:8180;

    server ktds.com:8280;

    fair no_rr;

}

server {

    location / {

        proxy_pass http://backend;

    }

}

 

fair 지시어

  fair : 기본적인 설정이며, 단순한 가중 최소 접속 라운드로빈으로 활성화된 접속자 수가 가장 적은 서버를 라운드로빈 방식으로 선택하여 요청을 보냅니다.

  fair no_rr (no roun-robin) : 라운드로빈 방식을 사용을 하지않고, 부하 양에 따라 다수의 백엔드를 배정하는 경우에 적용할 수 있다. 이 방식은 필요한 만큼의 백엔드를 사용할 수 있도록 보장을 한다.(권장설정 값)

  fair weight_mode=idle no_rr : 최소한의 백엔드 서버 풀 안에서 부하분산을 수행.

  fair weight_mode=peak : 백엔드 서버가 더이상의 요청을 처리를 못한 busy 상태일 경우 클라이언트에 502 에러로 응답을 합니다. 

 

참고 URL : https://nginx.localdomain.pl/wiki/UpstreamFair

 

by 김현수(7월)

posted by lovelywas

 

작은사이트에서는 하나의 백엔드 프로세스(WAS)만 있으면 유입되는 모든 트래픽을 처리하는데 충분합니다. 하지만 사용자가 점점 증가를 함에따라 다중 백엔드 설정이 필요한데 그 방법에 대해서 알아보도록 하겠습니다.

 

upstream backend {
    server ktds.com:8280;

    # 10초동안 한번의 에러가 발생하면 작동하지 않는 서버로 간주.

    server ktds.com:8080            weight=5;

    # 백엔드 서버에 대한 가중치 설정.
    server ktds.com:8180            max_fails=3 fail_timeout=30s;

    # 30초동안 3번의 요청 실패가 발생하면 이 서버는 작동하지 않는 서버로 간주.

    server ktds.com:8280            backup;

    server ktds.com:8380            backup;

    # primary서버가 사용불가시 backup서버에서 요청을 수행합니다.
}

server {

    location / {

        proxy_pass http://backend;

        health_check;

    }

}

 

 

서버로 보내는 모든 요청은 라운드로빈(round-robin) 방식으로 백엔드 서버에 전달이 됩니다.

 

weight=number

    백엔드 서버에 대한 가중치 설정

    기본 설정값 = 1

 

max_fails=number

    요청실패회수에 대해서 임계치를 지정을 하고, 해당 회수에 도달하면 작동하지 않는 서버로 간주

    기본 설정값 = 1

 

max_timeout=number

    설정한 시간동안 요청이 성공을 하지 못할 경우 작동하지 않는 서버로 간주

    기본 설정값 = 10s

   

backup

    primary서버가 사용불가시 backup서버에서 요청을 수행합니다.

 

 

by. 김현수(7월)   

posted by lovelywas

Nginx를 Reverse Proxy 웹서버로 사용할때의 캐시 사용방법

http {

    include       mime.types;

    default_type  application/octet-stream;

    proxy_cache_path /nginx/nginx-1.6/cache levels=1:2 key_zone=my-cache:8m max_size=1000m inactive=600m;

    proxy_temp_path /nginx/nginx-1.6/tmp;


    ... 중략


    server {

        listen       80;

        server_name  localhost;


        #charset koi8-r;


        #access_log  logs/host.access.log  main;


        location / {

            root   html;

            index  index.html index.htm;

        }

        location ~ \.jsp$ {

            include proxy.conf;

            proxy_pass  http://127.0.0.1:8080;

            proxy_cache my-cache;

            proxy_cache_valid 200 302 60m; 

            proxy_cache_valid 404 1m;

        }

    }

}


최대 1,000MB의 캐시를 만들어 HTTP 응답코드가 200 또는 302일 경우 60분동안 캐시에 저장을 하고 응답코드가 404인 경우에는 1분동안 캐시에 저장하는 설정입니다.

 

자주쓰는 캐시설정 지시어

 : proxy_cache 지시어

   설명 : 캐시 존을 정의합니다. 캐시존에 부여된 식별자를 이용해 다른지시어에서 사용을 한다.

   syntax : proxy_cache zonename | off;

   default : proxy_cache off;

   사용 예) proxy_cache cache1;    // cache1 이라는 캐시존을 정의

   context : http, server, location

 

 : proxy_cache_path 지시어

   설명 : 캐시파과 매개변수를 저장하기 위한 디렉토리를 지정한다.

   syntax : proxy_cache_path path [levels=levels] keys_zone=name:size [inactive=time]

                    [maxsize=size] [loader_files=number] [loader_sleep=time] [loader_threshold=time]

    - level : 하위 디렉토리의 깊이를 나타낸다( 보통 1:2 정도면 충분함 )

    - key_zone : proxy_cache 지시어로 정의한 캐시 존을 이용할 수 있게 하며, size는 해당 캐시존의 크기이다.

    - inactive : 캐시된 응답이 지정한 시간만큼 사용되지 않으면 캐시로부터 제거된다.

    - max_size : 전체 캐시의 최대 크기를 정의한다.

   사용 예) proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=cache1:10m max_size=300M;

   default : 없음

   context : http

 

 : proxy_cache_key 지시어

   설명 : 캐시 항목들을 서로 구분하는 캐시 키(cache key)를 정의한다.

      캐시 키가 $request_uri로 설정되어있으면, request_uri이 같은 모든 요청은 같은 캐시 항목에 대응된다.

   syntax : proxy_cache_key string;

   사용 예) proxy_cache_key "$schema$host$request_uri $cookie_user";

   default : proxy_cache_key $schema$proxy_home$request_uri;

   context : http, server, location

 

 : proxy_cache_bypass 지시어

   설명 : 응답에 캐시를 적용하지 않을 조건을 지정한다.

            문자열 변수가 비어 있지 않거나 "0"이 아니면, 캐시로부터 응답을 가져오지 않는다.

            동일한 지시어로 proxy_no_cache 지시어가 있다.(syntax 동일함)

   syntax : proxy_cache_bypass string ... ;

   default : 없음.

   context : http, server, location

 

 : proxy_cache_method 지시어

   설명 : 캐시가 적용되는 HTTP 메소드를 정의한다.

   syntax : proxy_cache_method GET | HEAD | POST;

   default : proxy_cache_method GET HEAD;   // 기본적으로 GET, HEAD는 포함되며, 해제할 수 없다.

   context : http, server, location

 

 : proxy_cache_min_uses 지시어

   설명 : 요청이 캐시되는 데 필요한 최소 요청 횟수를 정의한다.

   syntax : proxy_cache_min_uses number;

   default : proxy_cache_min_uses 1;   // 기본적으로 한번의 요청만으로도 캐시된다.

                                                   같은 캐시키를 갖는 이후의 요청은 캐시된 응답을 수신하게 된다.

   context : http, server, location

 

 : proxy_cache_valid 지시어

   설명 : 프록시되는 서버(backend)로부터의 응답에 따른 캐시의 유효시간 설정

   syntax : proxy_cache_valid code1 [code2 ...] time;

   사용 예) proxy_cache_valid 404 1m;         // 응답코드 404는 1분 동안 캐시

               proxy_cache_valid 500 502 504 5m;   // 응답코드 500, 502, 504는 5분동안 캐시

               proxy_cache_valid 200 10;          // 응답코드 200은 10분이상 캐시

   default : 없음

   context : http, server, location



by 김현수

 

'1. 미들웨어이야기 > 04. Nginx' 카테고리의 다른 글

Nginx 백엔드 서버 부하분산 설정  (0) 2014.07.28
Nginx 다중 백엔드 설정  (0) 2014.07.28
Nginx Reverse Proxy cache 설정  (0) 2014.05.13
Nginx JBoss 연동(Reverse Proxy 사용)  (0) 2014.05.07
Nginx 설치 / -configure 옵션  (0) 2014.05.07
Nginx 설치  (0) 2014.04.23
posted by lovelywas
prev 1 2 next