참고자료
풀스택을 위한 도커와 최신 서버 기술(리눅스, nginx, AWS, HTTPS, flask 배포) [풀스택 Part3] 강의 | 잔재
잔재미코딩 DaveLee | 본 강의는 풀스택 강의 시리즈 Part3 강의로 최신 서버 기술과 도커 기술을 탄탄하게 익히는 강의입니다. 본 강의는 실질적으로 도커를 내 기술 스택에 포함시킬 수 있도록, 도
www.inflearn.com
우선 프록시라는 단어는 매개체, 대리자이다. 그래서 nginx도 reverse proxy라는 단어를 종종 사용하는데 같은 의미의 프록시다.
Proxy Server
클라이언트가 자신을 통해, 다른 네트워크 서비스에 접속하게 해줄 수 있는 서버
Forward Proxy
클라이언트가 외부 인터넷에 직접 접근하는 게 아니라, 클라이언트가 Proxy Server에 외부 인터넷 접근 요청을 하고, Proxy Server가 외부 인터넷에 대신 접속하여 결과를 받은 후 클라이언트에게 전달하는 서버
Reverse Proxy
클라이언트가 Reverse Proxy에 요청하면, Reverse Proxy가 관련 요청에 따라 적절한 내부 서버에 접속하여 결과를 받은 후 클라이언트에게 전달
그러니까, 말이 조금 애매한데 하나의 네트워크 안에 존재하는 클라이언트가 해당 네트워크가 아니라 외부에 있는 서비스에 접근 요청을 할때 그 요청을 대신 해주는 것이 Forward Proxy라고 생각하면 되고, 외부에 있는 특정 호스트가 특정 네트워크에 요청을 하면 그 네트워크에 요청을 처리할 수 있는 서비스가 요청을 직접 받는게 아니라 프록시를 통해서 요청을 하고 프록시가 그 요청을 처리할 수 있는 적절한 서비스를 찾아 요청을 대신 전달해주고 받은 응답을 외부 특정 호스트에게 돌려주는 게 Reverse Proxy이다.
우리가 만약 서비스를 운영하고 Nginx를 사용해서 서비스를 외부에 노출 시킨다면 그건 Reverse Proxy를 사용하는 것이다. 아래와 같은 구조를 의미한다.
Reverse Proxy를 사용하면 어떤 장점이 있을까? 외부에서 접근하려는 서비스가 데이터베이스같은 굉장히 보안적으로 중요한 데이터라면 이 프록시가 접근을 막을 수 있다. 또한, 한 서비스에 대한 요청 트래픽이 매우 많아질 때 해당 서비스를 여러개로 복제해 로드 밸런싱도 할 수 있다.
그러면, 이 구조 자체는 이해를 했다. 어떻게 그럼 프록시가 들어오는 요청이 A 서비스에 가야하는구나, B 서비스에 가야하는구나를 알까?
- URI
- 포트
이 두가지를 통해서 알 수 있다. 이제 이것도 테스트를 해보자.
docker-compose로 Nginx proxy 띄우기 (포트로 서비스 구분)
우선, docker-compose 파일을 하나 준비했다.
docker-compose.yml
version: "3"
services:
nginxproxy:
image: nginx:1.18.0
ports:
- "8080:8080"
- "8081:8081"
restart: always
volumes:
- "./nginx/nginx.conf:/etc/nginx/nginx.conf"
nginx:
depends_on:
- nginxproxy
image: nginx:1.18.0
restart: always
apache:
depends_on:
- nginxproxy
image: httpd:2.4.46
restart: always- 3개의 서비스가 있다.
- 프록시 역할을 하는 nginx, 그냥 nginx, 그냥 apache
- 프록시 역할을 하는 nginx는 8080, 8081 포트를 열어두었다.
- 프록시 역할을 하는 nginx는 볼륨 마운트도 하는데 해당 파일은 nginx 설정 파일이다.
- 그래서 결론부터 말하면, 프록시 역할을 하는 nginx가 외부 요청에 따라 그냥 nginx 서비스를 호출하거나, 그냥 apache 서비스를 호출한다.
그래서 그 nginx 설정 파일을 열어보면 다음과 같다.
./nginx/nginx.conf
user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
events {
worker_connections 1024;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
sendfile on;
keepalive_timeout 65;
upstream docker-nginx {
server nginx:80;
}
upstream docker-apache {
server apache:80;
}
server {
listen 8080;
location / {
proxy_pass http://docker-nginx;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $server_name;
}
}
server {
listen 8081;
location / {
proxy_pass http://docker-apache;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $server_name;
}
}
}한 부분씩 자세히 알아보자.
events {
worker_connections 1024;
}- events {...} 블록은 nginx의 이벤트 처리 방식을 설정하는 곳이다.
- worker_connections 1024; 는 각 워커 프로세스가 동시에 처리할 수 있는 최대 클라이언트 연결 수를 1024로 지정한다는 의미이다. 그래서 만약, nginx가 4개의 워커 프로세스를 사용하고 있다면 최대 4 * 1024 = 4096개의 동시 연결을 처리할 수 있게 된다.
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
sendfile on;
keepalive_timeout 65;
...
}- include /etc/nginx/mime.types; → 이 설정은 nginx가 MIME 타입을 정의한 파일을 포함시키는 지시어다. 이 mime.types 파일은 다양한 파일 확장자와 그에 해당하는 MIME 타입을 매핑한 정보가 들어있다. 예를 들어, .html 파일은 text/html 타입으로, .jpg 파일은 image/jpeg 타입으로 처리되게끔 정의한 파일이다. 그래서 nginx는 이 파일을 사용해서 요청된 파일의 MIME 타입을 올바르게 설정하고, 클라이언트에 적절한 응답 헤더를 보내게 된다.
- default_type application/octet-stream; → 이 설정은 요청된 파일의 MIME 타입을 자동으로 결정할 수 없을 때, 기본 MIME 타입을 설정하는 지시어다. 그래서 기본 MIME 타입으로 application/octet-stream으로 지정한다는 의미이다. application/octet-stream는 기본 바이너리 데이터 타입을 의미하며, Nginx가 MIME 타입을 특정하지 못하는 파일(확장자나 내용이 불분명한 파일)을 바이너리 파일로 취급한다. 이는 파일 다운로드를 처리할 때 많이 사용되는 타입이다.
- log_format main '...' → 로그 형식을 지정한다. main 이라는 이름으로 새로운 로그 형식을 정의하고 있다.
- $remote_addr: 클라이언트의 IP주소
- $remote_user: 클라이언트가 인증된 사용자명(있을 경우)
- $time_local: 로컬 서버 시간
- $request: 클라이언트가 보낸 HTTP 요청 라인(메서드, URI, 프로토콜)
- $status: HTTP 응답 상태 코드
- $body_bytes_sent: 클라이언트로 전송된 응답 본문의 바이트 수
- $http_referer: 클라이언트가 요청을 보낼 때 보낸 Referer 헤더 값(클라이언트가 이전에 방문한 페이지 정보)
- $http_user_agent: 클라이언트의 웹 브라우저 및 운영체제 정보
- $http_x_forwarded_for: 프록시를 거친 요청에 대해 클라이언트의 원래 IP 주소를 기록하는 값(프록시 서버에서 사용)
- access_log /var/log/nginx/access.log main; → 접속 로그를 기록할 파일의 경로와 사용할 로그 형식을 설정하는 지시어이다. 그래서 접속 로그가 저장될 파일 경로는 /var/log/nginx/access.log이고, 그 때 로그의 형식은 앞서 정의한 main이다.
- sendfile on; → Nginx가 파일을 클라이언트에게 전송할 때 사용하는 파일 전송 방식을 설정하는 지시어이다. on으로 설정하면 nginx는 sendfile 시스템 호출을 사용하여 파일 전송을 효율적으로 처리한다. 이 방식은 nginx가 파일을 직접 읽고 전송하는 대신 커널이 파일을 바로 전송하게 함으로써 성능을 크게 향상 시킬 수 있다. 주로 정적 파일(이미지, CSS, JavaScript 등)을 빠르게 전송하는 데 사용된다.
- keepalive_timeout 65; → 클라이언트와 Nginx 서버 간 유지되는 연결의 유효 시간(초 단위)을 설정하는 지시어이다. 65초로 설정되어 있기 떄문에 클라이언트와 서버 간 연결이 65초 동안 유지됩니다. 이 시간 동안 추가적인 요청이 발생하면 새로운 TCP 연결을 생성하지 않고 기존 연결을 재사용 한다.
upstream docker-nginx {
server nginx:80;
}
upstream docker-apache {
server apache:80;
}- docker-compose를 사용하면 같은 네트워크 안에서 서비스 명으로 각각의 서비스를 호출할 수 있는데 그것에 대한 정보이다. docker-nginx라는 이름은 아무렇게나 지을 수 있다. 저렇게 꼭 지어야 하는 게 아니다. 그래서 docker-nginx라는 키워드를 사용하면 `nginx`라는 docker-compose로 띄운 서비스의 80포트로 요청을 전달한다.
- docker-apache도 마찬가지다. 이름은 아무렇게나 지어도 된다. 그리고 이 docker-apache라는 키워드를 사용하면, `apache`라는 docker-compose로 띄운 서비스의 80포트로 요청을 전달한다.
- 쉽게 말해 그냥, docker-nginx, docker-compose는 alias같은 것이다.
server {
listen 8080;
location / {
proxy_pass http://docker-nginx;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $server_name;
}
}
server {
listen 8081;
location / {
proxy_pass http://docker-apache;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $server_name;
}
}- 저번 포스팅에서도 본 적이 있는 server 블록이다.
- 첫번째 server 블록 (8080 포트)
- listen 8080 nginx가 8080번 포트로 들어오는 요청을 수신하도록 설정했다.
- location / {...} 로 루트 경로(/)로 들어오는 모든 요청에 대한 설정을 했다.
- proxy_pass http://docker-nginx; 모든 요청을 docker-nginx로 정의된 서버로 요청을 전달한다.
- proxy_redirect off; 프록시 서버가 리다이렉션 응답을 받을 때, 리다이렉션 URL을 변경하지 않도록 설정한다.
- proxy_set_header Host $host; 클라이언트가 보낸 호스트 헤더를 그대로 서버에 전달한다.
- proxy_set_header X-Real-IP $remote_addr; 클라이언트의 실제 IP 주소를 X-Real-IP 헤더로 전달한다.
- proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 클라이언트의 원래 IP 주소와 프록시를 거친 IP 주소들을 X-Forwarded-For 헤더로 전달한다.(그러니까 프록시에 또 프록시를 거칠수도 있으니까 말이다)
- proxy_set_header X-Forwarded-Host $server_name; 서버의 이름을 X-Forwarded-Host 헤더로 전달한다.
- 두번째 server 블록 (8081 포트)
- listen 8081 nginx가 8081번 포트로 들어오는 요청을 수신하도록 설정했다.
- location / {...} 로 루트 경로(/)로 들어오는 모든 요청에 대한 설정을 했다.
- proxy_pass http://docker-apache; 모든 요청을 docker-apache로 정의된 서버로 요청을 전달한다.
이렇게 설정된 nginx 설정 파일이다. 이 파일을 nginx proxy가 사용할 것이다. 이제 docker-compose를 띄워보자.
#docker-compose.yml 파일이 있는 경로에서
docker-compose up -d
잘 띄워졌으면 다음 경로에 각각 요청해보자.
우리가 매핑한 정보대로 8080은 nginx 서버를, 8081은 apache 서버를 띄워주고 있다. 이게 nginx reverse proxy를 띄우고 각 서비스를 포트로 구분해서 포워딩하는 내용이다.
docker-compose로 Nginx proxy 띄우기 (경로로 서비스 구분)
이번엔 포트말고 경로로 두 서비스를 구분해보자.
docker-compose.yml
version: "3"
services:
nginxproxy:
image: nginx:1.18.0
ports:
- "80:80"
restart: always
volumes:
- "./nginx/nginx.conf:/etc/nginx/nginx.conf"
nginx:
depends_on:
- nginxproxy
image: nginx:1.18.0
restart: always
apache:
depends_on:
- nginxproxy
image: httpd:2.4.46
restart: always- 이번엔 proxy 역할을 하는 nginx의 포트를 80만 열어두었다.
- 마찬가지로 nginx.conf 파일을 그대로 컨테이너에 옮겨주는데 해당 설정 파일은 아래와 같다.
user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
events {
worker_connections 1024;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
sendfile on;
keepalive_timeout 65;
upstream docker-nginx {
server nginx:80;
}
upstream docker-apache {
server apache:80;
}
server {
listen 80;
location /nginx/ {
proxy_pass http://docker-nginx;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $server_name;
}
location /apache/ {
proxy_pass http://docker-apache;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $server_name;
}
}
}- 이번엔 서버 블록이 하나만 있고 80 포트로 listen하고 있다.
- 그리고 location으로 경로를 `/nginx/`, `/apache/` 로 구분지었다.
이 상태로 docker-compose를 띄워보자.
# docker-compose.yml 파일이 있는 경로에서
docker-compose up -d
잘 띄워졌다. 그럼 한번 브라우저에서 접속해볼까?
어라? nginx가 띄워지긴 한 모양인데 404가 떴다. 즉, 우리가 원하는 파일을 못 찾은것이다. 왜 그럴까?
우선 접속 경로는 `/nginx/`이다. 그럼 nginx 프록시 서버 설정에 의해서 docker-nginx가 지정한 nginx 서버로 요청을 전달할 것이다. 근데, 이 전달받은 서버는 nginx이다. 즉, 이 내부에 있는 nginx 서버는 어떤 경로를 받냐면 `/nginx/`를 그대로 받는데 이 내부에 있는 nginx 서버는 해당 경로를 모른다. 왜? 우리가 설정한 적이 없으니까!
무슨 말인지 말로만 하면 이해가 안가니까, 내부 nginx 컨테이너로 들어가보자.
들어가기 위해 내부 nginx 컨테이너 이름을 확인해보자. 확인했으면 다음 명령어를 실행한다.
docker exec -it 04_nginx_proxy_path-nginx-1 /bin/bash
들어왔으면 설정 파일 위치를 찾자.
$ find -name nginx.conf
./etc/nginx/nginx.conf
위 예시처럼 찾았으면 해당 파일을 열어보면, 아래와 같이 http 블록안에 server 블록이 있지 않고 include로 나뉘어져 있다.
그럼 저 경로로 가서 어떤 파일이 있는지 확인을 해보면, default.conf 파일이 존재한다.
이 파일을 열어보면, 아래와 같이 80으로 listen하고 있는 서버가 하나 있지만, 이 서버의 location 정보에 /nginx/는 없다.
그렇다면, 모든 요청에 대해 location / {...} 가 처리하게 되고 이 녀석의 root 경로는 `/usr/share/nginx/html`이다.
그럼 외부에서 `/nginx/` 이런 경로로 요청이 들어오면 /usr/share/nginx/html/nginx/index.html 파일을 찾을것이다.
왜냐하면 `/nginx/`는 마지막에 `/`만 붙고 다른 URI가 안 붙었으니 디렉토리를 찾고 그 안에서 index로 설정한 index.html이나 index.htm 파일을 찾을 것이니까.
그래서 /usr/share/nginx/html 경로에 nginx 폴더를 일단 만들어야 한다.
# /usr/share/nginx/html 경로에서
mkdir nginx
그리고 이 폴더안에 /usr/share/nginx/html 경로에 있던 index.html 파일을 복사해서 넣어두자.
그러고 다시 브라우저에서 접속해보면, 아래와 같이 잘 나올것이다.
apache도 같은 이유로 제대로 나오지는 않을 것이다. 이왕 한 김에 apache도 제대로 나오도록 작업해보자.
우선 컨테이너 내부로 들어와서, 아파치의 설정 파일 경로는 여기에 있다.
/usr/local/apache2/conf
이 경로 안에 `httpd.conf` 파일이 설정 파일이다. 이 설정 파일을 열어보면,
위 사진과 같이 root 경로는 `/usr/local/apache2`이다.
여기로 가보면, 실제 파일을 두는 경로는 `/usr/local/apache2/htdocs` 이곳이다.
이 경로에서 apache라는 폴더를 만들고 index.html 파일을 복사하자.
그러고 나서 브라우저에서 `/apache/`로 접속해보면, 잘 나온다.
근데, 솔직히 이 작업은 너무 귀찮다. 왜냐하면, 일단 위에서 했던 작업들이 필요하기 때문이다.
Nginx 프록시 서버에서 경로 설정으로 location /nginx/ {...} 이렇게 한 순간 요청을 할 때, `/nginx/`이렇게 요청을 할 것이고, 그럼 그 요청 경로가 그대로 내부 nginx 서버에 전달될텐데 지금처럼 내부 nginx 서버에는 이 경로에 대해 정의한 것이 없으니 위처럼 작업이 필요해진다.
이럴때 만약 `http://localhost/nginx` 이렇게 요청한 것을 프록시 서버가 전달할 때는 `http://localhost`로 바꿔주면 얼마나 좋을까? 그럼 내부 nginx 서버에서는 따로 경로에 대한 작업을 할 필요가 없어질 테니 말이다.
rewrite 옵션
위의 문제를 이렇게 해결할 수 있다.
location /nginx/ {
rewrite ^/nginx(.*)$ $1 break;
proxy_pass http://docker-nginx;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $server_name;
}- 위 코드를 보면, rewrite 라는 옵션이 추가됐음을 확인할 수 있다. 그리고 정규 표현식이 나오고 뭐 등등 복잡하다.
표현식은 이렇다.
rewrite regex URL [flag]- regex: 매칭되는 URL 패턴을 설정한다.
- URL: 변경할 URL 기재
- flag: 추가적인 옵션을 기재, 여기서는 break를 사용했는데 이 break는 어떤거냐면, 여러 개의 location이 있을 때, 변경된 URL이 그 여러개의 location 중 우연히 매칭이 될 수도 있기 때문에 break를 사용해서 변경된 URL은 다시 다른 location 설정에 따르지 않고 현재의 location 설정에만 적용한다는 의미이다.
그럼 저 `^/nginx(.*)$ $1`이 의미하는 건 무엇이냐면,
- ^: 시작을 나타낸다.
- /nginx: 시작한 후 나오는 문자
- (.*): 임의의 문자열을 나타낸다.
- `.`: 임의의 한 문자를 나타낸다. (만약, 진짜 `.`을 의미하게 하고 싶으면 `\.` 이렇게 역슬래시를 붙여준다.)
- `*`: 0회 이상의 문자를 나타낸다.
- $: 문자 끝을 나타낸다.
- $1: (.*)을 의미한다. 즉, ()로 묶인 부분을 $1로 받아올 수 있다.
- 그래서 만약, `^/nginx(.*)/abc/(.*)$ $1` 이렇게 되어 있으면, 이제 $1, $2로 저 두개의 괄호 묶음을 가져올 수도 있다.
그럼 만약, `localhost/nginx/`로 요청이 들어오면, `localhost/`로 변경이 되는 것이다.
그래서 이 옵션을 적용한 파일은 이렇게 생겼다. 다른 것 없이 그냥 rewrite 더해주면 된다.
user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
events {
worker_connections 1024;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
sendfile on;
keepalive_timeout 65;
upstream docker-nginx {
server nginx:80;
}
upstream docker-apache {
server apache:80;
}
server {
listen 80;
location /nginx/ {
rewrite ^/nginx(.*)$ $1 break;
proxy_pass http://docker-nginx;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $server_name;
}
location /apache/ {
rewrite ^/apache(.*)$ $1 break;
proxy_pass http://docker-apache;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $server_name;
}
}
}
이대로 docker-compose를 다시 실행해서 확인해보자!
결과는 동일하게 잘 나오지만, 난 내부 nginx 서버에 어떠한 경로도 적용해주지 않았다. 즉, 저 rewrite 옵션으로 인해 내부 nginx에 요청을 전달할 때는 `http://localhost`로 그냥 간 것이다.
그리고 좋은 사이트 하나가 있다.
https://nginx.viraptor.info/
nginx.viraptor.info
이 사이트는 뭐냐면, 이제 저렇게 여러 location이 막 있을 때, 어떤 location에 현재 요청이 걸리는지 헷갈릴 때가 언젠가 생긴다. 그럴때 그걸 알려주는 것이다.
추가적인 내용들
사실 nginx 설정이란 게 굉장히 다양하고 상황에 따라 달라지기 때문에 그때그때 필요한 것들을 찾아가야 한다. 그럼에도 불구하고, 자주 사용되는 것들은 정리해보려고 한다.
에러 페이지 설정
error_page 403 404 405 406 411 497 500 501 502 503 504 505 /error.html;
location = /error.html {
root /usr/share/nginx/html;
}- error_page 지시어는 HTTP 상태 코드가 403, 404, ... 505 인 경우 `/error.html` 경로로 리다이렉션 하라는 의미이다. 즉, 여기서는 `/error.html` 페이지를 클라이언트에게 보여주겠다는 의미가 된다.
- location = /error.html { ... } 은 경로가 정확하게(=) `/error.html` 인 경우에 이 정의를 따른다.
정규 표현식을 사용하는 location
location ~ \.php$ {
...
}- `~` 표시는 정규 표현식을 사용하겠다는 의미가 된다. 그래서 \.php$는 `\.`가 정확히 딱 `.`을 의미하고 php가 나오고 $는 끝을 의미하니까 경로가 .php로 끝나는 경우를 의미한다.
캐시 설정
location ~* \.(ico|css|js|glf|jpe?g|png)$ {
expires max;
add_header Pragma public;
add_header Cache-Control "public, must-revalidate, proxy-revalidate";
}- 정적 파일(CSS, JS, 이미지, ico)은 변경될 가능성이 극히 드물다. 그런데 그런 파일들을 요청이 들어올때마다 HTTP 요청 응답으로 처리하면 속도가 느리니 캐쉬 설정을 하는 것이다.
- `~*`: 의미하는건 정규표현식은 정규표현식인데 대소문자를 구분하지 않겠다는 의미이다.
- `\.(ico|css|js|glf|jpe?g|png)$`: 의미하는 건 .ico 또는 .css 또는 .js 또는 .glf 또는 .jpeg 또는 .jpg 또는 .png 대상을 의미한다. 저기 jpe?g는 e가 있을수도 없을수도 있다는 의미이다.
'Nginx' 카테고리의 다른 글
| Nginx 기본 이해 (구동 방식, 설정 파일) (0) | 2024.09.19 |
|---|