얼마 전 회사 웹사이트 테스트용 서버에 로그인했는데 우연히 access.log.gz 파일 패키지를 보고 호기심이 생겨 원격 서버에서 로컬로 다운로드한 후 압축을 풀고 열어보았습니다. 액세스 로그 예전에는 그 회사의 운영 및 유지 관리 담당자가 액세스 로그에 대해 언급하는 것을 늘 들었지만 지금은 그게 무엇인지 몰랐습니다. 그럼 이해가 안 되면 물어봐야죠. nginx라는 서버 소프트웨어죠. 잠깐의 여유 시간을 갖고, 내 컴퓨터에 nginx를 설치할 수 있을까 하는 생각이 들었습니다. 일상적인 개발과 디버깅 중에 가장 많이 사용되는 포트도 모니터링할 수 있다는 점은 의미가 없다고 생각될 수도 있습니다. 일종의 학습은 결국 책이나 자료를 읽는 것보다 직접 해보는 것이 더 깊은 경험을 하게 될 것입니다. 오늘은 구성에 대해서만 이야기하겠습니다. 연구가 진행되면서 로드 밸런싱, 역방향 프록시, 최적화 등에 대해서도 접하게 될 것입니다. 잘못된 것이 있으면 바로잡아주시고, 서로 배워가며 함께 발전해 나가시기 바랍니다!
Apaceh 및 기타 제품과 비교하면 Nginx에는 많은 장점이 있습니다. 여기서는 그다지 강조하지 않겠습니다. 높은 동시 연결, 낮은 메모리 소비, 저렴한 비용입니다. 간단한 구성 파일 등
(1) 설치
ubuntu 시스템에 nginx를 설치하는 것은 매우 간단하며 명령어 하나만으로 설치가 가능합니다.
sudo apt-get install nginx
그런데 설치 중 오류가 발생하면 터미널에 "패키지 목록이나 상태 파일을 구문 분석하거나 열 수 없습니다"라는 메시지가 나타납니다. 구체적으로 다음과 같습니다.
E: 패키지가 없는 섹션이 발생했습니다: 헤더
E: MergeList /var/lib/apt/lists/cn.archive.ubuntu.com_ubuntu_dists_natty_main_i18n_Translation-en 관련 문제
E: 패키지 목록이나 상태 파일을 구문 분석하거나 열 수 없습니다.
해결책:
sudo rm /var/lib/apt/lists/* -vf //삭제할 수 없는 경우 강제 삭제를 사용하고 -r 매개변수를 추가할 수 있습니다.
sudo apt-get update
또 다른 요점은 Apache가 컴퓨터에 설치되어 있고 이미 실행 중이라면 Apache를 중지해야 한다는 점입니다. Apache와 Nginx의 기본 포트는 모두 80이기 때문입니다.
설치가 성공적으로 완료되면 실행 가능한 명령이 생성됩니다. 터미널을 열고 nginx -h 명령을 입력하면 일부 명령 매개변수 정보가 나타납니다.
nginx -h 명령 도움말 보기
nginx -v 버전 정보 표시
nginx -V 버전 정보 및 구성 옵션 표시
nginx - t 구성 파일 테스트
nginx -T 구성 파일 테스트 및 덤프
nginx -q 구성 테스트 중 오류가 아닌 메시지 억제
nginx -s signal 신호에 중지, nginx 중지, 종료, 다시 열기가 포함된 기본 프로그램;
nginx -p prefix 접두사 경로를 설정합니다. 기본값은 /usr/share/nginx/입니다.
nginx -c filename 구성 파일을 설정합니다. 기본값은 /etc/nginx/nginx입니다. conf
ngnix -g 지시문은 구성 파일의 범위를 넘어서는 전역 지시문을 설정합니다.
참고: 이 지침을 사용할 때 오류가 발생하면 권한 문제일 수 있습니다. 실행.
(2) 구성 파일
주요 구성 파일은 nginx.conf이고, 기본 경로는 /etc/nginx/
에 관련된 파일입니다. PHP는 fastcgi_params 이고 Python과 관련된 것은 uwsgi_params
구성 파일 매개변수이며 그 의미는 다음과 같습니다:
user www www;
Nginx 사용자 및 그룹. 창 아래에
worker_processes 8을
개 지정하지 마세요. 하드웨어 조정에 따라 일반적으로 총 CPU 코어 수와 같거나 총 코어 수의 두 배입니다.
error_log /var/logs/error.log crit;
오류 로그 저장 경로 및 수준, 수준은 [debug|info|notice|warn|error|crdit]일 수 있습니다
각 오류 로그 수준은 블로그 게시물 http://blog.csdn.net/solmyr_biti/article/details/50634533
pid /run/nginx.pid;
을 참조하세요. 🎜>pid 프로세스 식별자 저장 경로입니다. pid 파일은 프로세스 ID를 기록하는 한 줄의 내용만 포함하는 텍스트 파일입니다. pid 파일의 목적은 프로세스가 여러 복사본을 시작하는 것을 방지하는 것입니다. pid 파일(고정 경로 및 고정 파일 이름)에 대한 쓰기 권한(F_WRLCK)을 획득한 프로세스만 정상적으로 시작하고 자신의 PID를 파일에 쓸 수 있습니다. 동일한 프로그램의 다른 중복 프로세스는 자동으로 종료됩니다. nginx의 pid 파일을 사용하여 nginx를 원활하게 중지하고 다시 시작하고 다시 시작할 수 있습니다. 명령 형식은 다음과 같습니다.TERM,INT 빠른 종료 QUIT 간편한 종료HUP HUP 원활한 종료, 구성 파일 다시 로드USER1 로그 파일 다시 열기, 로그를 잘라낼 때 매우 유용함
USER2 실행 파일을 원활하게 업그레이드WINCH 작업자 프로세스를 정상적으로 종료
이 명령은 nginx 프로세스에서 열리는 최대 파일 설명자 수를 나타냅니다. 이론적인 값은 최대 열린 파일 수(ulimit -n)를 nginx 프로세스 수로 나눈 값입니다. 매우 균일하므로 최종 값을 ulimit -n과 일치하게 유지하는 것이 가장 좋습니다.
이제 Linux 2.6 커널에서 열려 있는 파일 수는 65535이고 이에 따라 Worker_rlimit_nofile은 65535로 채워져야 합니다.
nginx 스케줄링 시 프로세스에 대한 요청 할당이 균형이 맞지 않기 때문이므로 10240을 입력하고 총 동시성이 30,000~40,000에 도달하면 프로세스 수가 10240을 초과하고 502 오류가 발생할 수 있습니다. 반환됩니다.
이벤트
{
epoll을 사용하세요.
epoll의 네트워크 I/O 모델을 사용하세요. Linux에서는 epoll을 권장하고 FreeBSD에서는 kqueue를 권장하며 window에는 지정되지 않습니다.
epoll, select, kqueue 사용시 관련 정보를 확인할 수 있습니다.
worker_connections 204800;
작업자 프로세스당 최대 연결 수입니다. 하드웨어에 맞게 조정하고 이전 작업 프로세스와 연계하여 사용하십시오. 가능한 한 크게 만들되 CPU를 100%로 실행하지 마십시오. 프로세스당 허용되는 최대 연결 수는 이론적으로 nginx 서버당 최대 연결 수입니다.
client_header_buffer_size 4k;
클라이언트 요청 헤더의 버퍼 크기입니다. 이는 시스템 페이징 크기에 따라 설정될 수 있습니다. 일반적으로 요청 헤더의 크기는 1k를 초과하지 않습니다. 그러나 시스템 페이징은 일반적으로 1k보다 크므로 페이징 크기는 여기에서 설정됩니다.
페이징 크기는 getconf PAGESIZE 명령을 사용하여 얻을 수 있습니다.
단, client_header_buffer_size가 4k를 초과하는 경우가 있는데, client_header_buffer_size 값을 "시스템 페이징 크기"의 정수배로 설정해야 합니다.
open_file_cache max=65535 inactive=60s;
이것은 열린 파일에 대한 캐시를 지정합니다. 기본적으로 활성화되지 않습니다. max는 캐시 수를 지정하는 것이 좋습니다. 비활성은 파일이 캐시 삭제를 요청받지 않은 시간을 의미합니다.
open_file_cache_valid 80s;
캐시된 유효한 정보를 얼마나 자주 확인하는지를 나타냅니다.
open_file_cache_min_uses 1;
open_file_cache 지시문의 비활성 매개변수 시간 내에 파일을 사용하는 최소 횟수입니다. 이 숫자를 초과하면 파일 설명자가 항상 캐시에서 열립니다. 위의 예에서 파일이 비활성 시간 내에 사용되지 않으면 제거됩니다.
}
##다음은 http 서버를 설정하고 역방향 프록시 기능을 사용하여 로드 밸런싱 지원을 제공하는 것입니다
http
{
include mime.types;
mime.type 파일에 정의된 MIME 유형 설정
default_type application/octet-stream;
log_format 메인 '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$ http_user_agent" "$ http_x_forwarded_for"';
log_format log404 '$status [$time_local] $remote_addr $host$request_uri $sent_http_location';
로그 형식 설정입니다.
$remote_addr 및 $http_x_forwarded_for는 클라이언트의 IP 주소를 기록하는 데 사용됩니다.
$remote_user: 클라이언트 사용자 이름을 기록하는 데 사용됩니다.
$time_local: 액세스 시간 및 시간대;
$request: 요청의 URL 및 http 프로토콜을 기록하는 데 사용됩니다.
$status: 요청 성공 상태를 기록하는 데 사용됩니다.
$body_bytes_sent: 클라이언트에 전송된 파일의 주요 내용 크기를 기록합니다.
$http_referer:
$http_user_agent에서 액세스한 페이지 링크를 기록하는 데 사용됩니다.
일반적으로 웹 서버는 역방향 프록시 뒤에 위치하므로 클라이언트의 IP 주소를 얻을 수 없습니다. $remote_add 를 통해 얻은 IP 주소는 역방향 프록시 서버의 IP 주소입니다. 역방향 프록시 서버는 전달된 요청의 http 헤더 정보에 x_forwarded_for 정보를 추가하여 원래 클라이언트의 IP 주소와 원래 클라이언트 요청의 서버 주소를 기록할 수 있습니다.
access_loglogs/host.access.log main;
access_loglogs/host.access.404.log log404;
log_format 명령을 사용하여 로그 형식을 설정한 후 , access_log 지시문을 사용하여 로그 파일의 저장 경로를 지정해야 합니다.
gzip on :
네트워크 전송을 줄이려면 gzip 압축 출력을 활성화하세요.
gzip_min_length 1k
압축이 허용되는 페이지의 최소 바이트 수를 설정합니다. 페이지 바이트 수는 헤더의 콘텐츠 길이에서 가져옵니다. 기본값은 20입니다. 바이트 수는 1k보다 크게 설정하는 것이 좋습니다. 1k보다 작으면 점점 더 압축될 수 있습니다.
gzip_buffers 4 16k
gzip 압축 결과 데이터 스트림을 저장하기 위해 여러 단위의 캐시를 확보하도록 시스템을 설정합니다. 4 16k는 16k 단위로 설치하려는 원본 데이터의 4배 크기인 16k 단위로 메모리를 신청한다는 뜻이다.
gzip_http_version 1.0
http 프로토콜의 버전을 식별하는 데 사용됩니다. 초기 브라우저는 Gzip 압축을 지원하지 않아 사용자에게 잘못된 문자가 표시되므로 이전 버전을 지원하기 위해 이 옵션이 추가되었습니다. Nginx의 역방향 프록시를 사용하고 Gzip 압축을 활성화하려면 최종 통신이 http/1.0이므로 1.0으로 설정하세요.
gzip_comp_level 6
gzip 압축 비율, 1은 압축 비율이 가장 작고 처리 속도가 가장 빠릅니다. 9는 압축 비율이 가장 크지만 처리 속도가 가장 느립니다(전송은 빠르지만 CPU를 더 많이 소모합니다)
gzip_types
MIME 유형과 일치합니다. 지정 여부에 관계없이 "text/html" 유형은 항상 압축됩니다.
gzip_proxied any
Nginx가 역방향 프록시로 사용될 때 활성화되며 백엔드 서버에서 반환된 결과의 압축을 활성화할지 여부를 결정합니다. 백엔드 서버는 "Via" 헤더를 반환해야 합니다.
의 gzip_vary는 http 헤더와 관련되어 있습니다. Vary: Accept-Encoding이 응답 헤더에 추가되어 프런트 엔드 캐시 서버가 gzip으로 압축된 페이지를 캐시할 수 있습니다. , Nginx로 압축된 Squid 캐시 데이터를 사용합니다. .
server_names_hash_bucket_size 128;
서버 이름을 저장하는 해시 테이블은 server_names_hash_max_size 및 server_names_hash_bucket_size 지침에 의해 제어됩니다. 매개변수 해시 버킷 크기는 항상 해시 테이블 크기와 동일하며 프로세서 캐시 크기의 배수입니다. 메모리에 대한 접근 횟수를 줄이면 프로세서에서 해시 테이블 키 값을 찾는 속도를 높일 수 있다. 해시 버킷 크기가 프로세서 캐시 크기와 같은 경우 키를 검색할 때 메모리 검색 횟수는 최악의 경우 2번입니다. 첫 번째는 저장 장치의 주소를 확인하는 것이고, 두 번째는 저장 장치의 키 값을 찾는 것입니다. 따라서 Nginx에서 해시 최대 크기 또는 해시 버킷 크기를 늘려야 한다는 메시지가 표시되면 가장 먼저 해야 할 일은 이전 매개변수의 크기를 늘리는 것입니다.
client_header_buffer_size 4k;
클라이언트 요청 헤더 내부 버퍼 크기입니다. 이는 시스템 페이징 크기에 따라 설정될 수 있습니다. 일반적으로 요청의 헤더 크기는 1k를 초과하지 않습니다. 그러나 시스템 페이징은 일반적으로 1k보다 크므로 페이징 크기는 여기에서 설정됩니다. 페이징 크기는 getconf PAGESIZE 명령을 사용하여 얻을 수 있습니다.
large_client_header_buffers 8 128k;
클라이언트 요청 헤더 버퍼 크기입니다. 기본적으로 nginx는 client_header_buffer_size 버퍼를 사용하여 헤더 값을 읽습니다.
헤더가 너무 크면 Large_client_header_buffers를 사용하여 읽습니다.
open_file_cache max=102400 inactive=20s;
이 지시문은 캐시 활성화 여부를 지정합니다. 최대 캐시 수와 캐시 시간도 지정됩니다. 20초 이상 비활성 상태인 후 지울 수 있도록 상대적으로 높은 최대 시간을 설정할 수 있습니다.
open_file_cache_errors on | off
기본값: open_file_cache_errors off 사용 가능한 필드: http, server , location, 이 지시어는 파일 검색 여부와 캐시 오류 로그를 지정합니다.
open_file_cache_min_uses
구문: open_file_cache_min_uses 번호 기본값: open_file_cache_min_uses 1 사용 필드: http, server, location 이 지시어는 지정합니다. open_file_cache 지시문의 유효하지 않은 매개변수에서 특정 시간 범위 내에서 사용할 수 있는 최소 파일 수입니다. 더 큰 값을 사용하면 파일 설명자가 항상 캐시에 열려 있습니다.
구문: open_file_cache_valid time 기본값: open_file_cache_valid 60 사용 필드: http, server, location 이 지시문은 open_file_cache에 캐시된 항목의 유효한 정보를 확인해야 하는 시기를 지정합니다. client_max_body_size 300m; >설정 nginx
sendfile on;
을 통해 업로드된 파일의 크기는 효율적인 파일 전송 모드를 켭니다. sendfile 명령은 nginx가 파일을 출력하기 위해 sendfile 함수를 호출할지 여부를 지정합니다. , 사용자 공간에서 커널 공간으로의 컨텍스트 전환을 줄입니다. 일반적인 응용 프로그램의 경우 켜기로 설정합니다. 다운로드와 같은 디스크 IO 부하가 많은 응용 프로그램에 사용되는 경우 디스크와 네트워크 I/O 처리 속도의 균형을 맞추고 시스템 부하를 줄이기 위해 끄기로 설정할 수 있습니다.
tcp_nopush on;
이 옵션은 소켓 사용의 TCP_CORK 옵션을 허용하거나 비활성화합니다.
proxy_connect_timeout 90; >백엔드 서버 연결 시간 초과 시간, 핸드셰이크 시작 및 응답 대기 시간
proxy_read_timeout 180;
연결 성공 후 백엔드 서버 응답 대기 시간, 실제로는 이미 처리를 기다리는 백엔드 큐(백엔드 서버가 요청을 처리하는 데 걸리는 시간이라고도 할 수 있음)
proxy_send_timeout 180;
백엔드 서버 데이터 반환 시간은 백엔드 서버가 지정된 시간 내에 모든 전송을 완료해야 함을 의미합니다. Data
proxy_buffer_size 4k
일반적으로 프록시 서버에서 읽은 응답의 첫 번째 부분에 대한 버퍼 크기를 설정합니다. 응답의 이 부분에는 기본적으로 작은 응답 헤더가 포함됩니다. 값의 크기는 Proxy_buffers 지시어에 지정된 버퍼의 크기이지만 더 작은
proxy_buffers 4 32k로 설정할 수 있습니다. >
는 프록시 서버에서 응답을 읽도록 설정되어 있으며, 기본값은 페이징 크기이며 운영 체제에 따라 4k 또는 8k일 수 있습니다.proxy_busy_buffers_size 64k; 고부하 시 버퍼 크기(proxy_buffers*2) proxy_temp_file_write_size 64k;캐시가 임시 파일에 응답하기 위해 서버에 의해 프록시되는 경우 이 옵션은 각각 작성되는 임시 파일의 크기를 제한합니다. 시간. Proxy_temp_path(컴파일 중에 지정할 수 있음)에 쓸 디렉터리입니다. proxy_temp_path /data0/proxy_temp_dir;proxy_temp_path와 Proxy_cache_path로 지정된 경로는 동일한 파티션에 있어야 합니다proxy_cache_path /data0/proxy_cache_dirlevel=1:2key_zone=cache_one:200m inactive=1d max_size=30g;
#메모리 캐시 공간 크기를 200MB로 설정하고, 1년간 접근하지 않은 콘텐츠 하드 디스크 캐시 공간 크기는 30GB입니다.
keepalive_timeout 120;
초 단위의 긴 연결 시간 초과 이 매개변수는 매우 민감하며 브라우저 유형, 백엔드 서버의 시간 초과 설정 및 운영 체제 설정과 관련됩니다. . 별도로 설정할 수 있는 글입니다. 긴 연결이 많은 수의 작은 파일을 요청하는 경우 연결을 다시 설정하는 비용을 줄일 수 있지만, 큰 파일을 업로드하는 경우 65초 이내에 업로드를 완료하지 못하면 실패하게 됩니다. 설정 시간이 너무 길고 사용자가 많은 경우 오랫동안 연결을 유지하면 많은 리소스를 차지하게 됩니다.
send_timeout 120;
은 클라이언트에 응답하기 위한 시간 초과 기간을 지정하는 데 사용됩니다. 이 시간 초과는 두 연결 활동 사이의 시간으로 제한됩니다. 클라이언트의 활동 없이 이 시간이 초과되면 Nginx는 연결을 닫습니다.
tcp_nodelay on;
nginx에게 데이터를 캐시하지 않고 하나씩 보내도록 지시합니다. 시간에 맞춰 데이터를 보내야 하는 경우 이 속성을 애플리케이션에 설정해야 합니다. 작은 데이터 정보가 전송됩니다. 반환 값은 즉시 얻을 수 없습니다.
client_body_buffer_size 512k;
256k와 같이 상대적으로 큰 값으로 설정하면 Firefox나 IE 브라우저를 사용하여 256k보다 작은 이미지를 제출하는 것이 정상입니다. 이 지시문을 주석 처리하고 운영 체제 페이지 크기(8k 또는 16k)의 두 배인 기본 client_body_buffer_size 설정을 사용하면 문제가 발생합니다.
firefox4.0을 사용하든 IE8.0을 사용하든 약 200k의 비교적 큰 이미지를 제출하면 500 내부 서버 오류가 반환됩니다.
proxy_intercept_errors on;
은 nginx 블록 응답을 사용한다는 의미입니다. HTTP 응답 코드 400 이상.
업스트림 베이켄드 {
서버 127.0.0.1:8027;
서버 127.0.0.1:8028;
서버 127.0.0.1:8029;
hash $request_uri;
}
이는 로드 밸런싱 문제를 염두에 두고 설계되었습니다.
nginx의 업스트림은 현재 다음 배포 방법을 지원합니다.
1. 폴링(기본값)
각 요청은 백엔드의 경우 하나씩 다른 백엔드 서버에 배포됩니다. 서버가 다운되면 자동으로 제거될 수 있습니다.
2. 가중치
는 폴링 확률을 지정하며, 백엔드 서버 성능이 고르지 않을 때 사용됩니다.
예:
업스트림 베이켄드 {
서버 192.168.0.14 가중치=10;
서버 192.168.0.15 가중치=10;
}
3. ip_hash
각 요청은 접속한 IP의 해시 결과에 따라 할당되므로 각 방문자는 백엔드 서버에 대한 고정 접속 권한을 갖게 되어 문제를 해결할 수 있습니다. 세션 문제.
예:
업스트림 베이켄드 {
ip_hash;
서버 192.168.0.14:88;
서버 192.168.0.15: 80 ;
}
4. 공정(타사)
백엔드 서버의 응답 시간에 따라 요청을 할당하고, 응답 시간이 짧은 요청을 먼저 할당합니다. .
업스트림 백엔드 {
서버 server1;
서버 server2;
fair;
}
5. url_hash (타사)
액세스한 URL의 해시 결과에 따라 요청을 분산하여 각 URL이 동일한 백엔드 서버로 연결되도록 백엔드 서버를 캐시할 때 더 효과적입니다.
예: 업스트림에 해시 문을 추가합니다. 가중치와 같은 다른 매개변수는 서버 문에 쓸 수 없습니다.
업스트림 백엔드 {
서버에 사용되는 해시 알고리즘입니다. squid1 :3128;
서버 squid2:3128;
hash $request_uri;
hash_method crc32;
}
#부하 정의 장치 IP 및 장치 상태 균형 조정
upstream bayend{
ip_hash;
server 127.0.0.1:9090 down;
server 127.0.0.1:8080 가중치 =2;
server 127.0.0.1:6060;
server 127.0.0.1:7070 backup;
}
사용해야 하는 서버에서 로드 밸런싱
proxy_pass http://bakend/;
각 장치의 상태가 다음으로 설정됩니다.
1.down은 단일 프런트 서버가 일시적으로 작동하지 않음을 의미합니다. 짐에 참여
2. 무게는 무게가 클수록 짐의 무게도 커지는 것을 의미합니다.
3.max_fails: 허용되는 요청 실패 횟수의 기본값은 1입니다. 최대 횟수를 초과하면 Proxy_next_upstream 모듈에서 정의한 오류가 반환됩니다.
4.fail_timeout: 요청 실패 후 일시 중지 시간 max_fails 실패.
5.백업: 백업이 아닌 다른 머신이 모두 다운되거나 사용 중일 때 백업 머신을 요청하세요. 따라서 이 기계의 압력은 가장 낮습니다.
nginx는 사용되지 않는 서버에서 사용할 수 있도록 동시에 여러 그룹의 로드 밸런싱 설정을 지원합니다.
Client_body_in_file_only를 On으로 설정하면 디버깅을 위해 클라이언트 게시물의 데이터를 파일에 기록할 수 있습니다.
client_body_temp_path는 기록되는 파일의 디렉터리를 3개까지 설정할 수 있습니다.
위치 URL을 일치시키거나 새로운 프록시 로드 밸런싱을 수행할 수 있습니다.
##가상 머신 구성
서버
{
listen 80;
수신 포트 구성
server_name image.***.com;
액세스 도메인 이름 구성
위치 ~* .(mp3|exe)$ {
정규식, "mp3 또는 exe"로 끝나는 주소에 대한 로드 밸런싱
proxy_pass http://img_relay$request_uri;
설정 프록시 서버 또는 소켓의 포트 및 URL
proxy_set_header 호스트 $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
위 세 줄의 목적은 프록시 서버에서 받은 사용자 정보를 실제 서버로 전달하는 것입니다
}
위치 /얼굴 {
if ($http_user_agent ~* "xnp") {
다시 쓰기 ^(.*)$ http://211.151.188.190:8080/ Face.jpg 리디렉션;
}
#이것은 Nginx의 Rewrite 규칙 문제와 관련이 있습니다. 공간이 제한되어 있으므로 다음 섹션에서 논의하겠습니다
proxy_pass http: //img_relay$request_uri;
proxy_set_header 호스트 $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header @fetch;
}
}
}
위에서도 nginx.conf 파일의 기본 형식이
......
http
> ......}
Nginx의 구성은 주요 기능입니다. CSS 파일의 스타일 정의와 비교할 수 있습니다. 하위 요소는 상위 요소의 스타일 정의를 상속하고 이를 재정의할지 여부를 선택할 수 있습니다. nginx 구성에도 비슷한 상속 관계가 있습니다.
nginx 구성의 상속 모델을 이해하려면 nginx 구성에 여러 블록이 있다는 것을 알아야 합니다. 예를 들어 서버 컨텍스트에 정의된 명령어가 서버에 저장됩니다. {} 블록. http 컨텍스트에 정의된 지시문은 http{} 블록에 저장됩니다.
nginx에는 6가지 가능한 컨텍스트가 있으며 높은 순서에서 낮은 순서는 다음과 같습니다.
Global
Http
Server
If
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
