Nginx 구성 파일 nginx.conf 구성 세부 사항은 다음과 같습니다.
user nginx nginx
Nginx 사용자 및 그룹: 사용자 그룹. 창
worker_processes
작업자 프로세스: 번호에 지정되지 않았습니다. 하드웨어 조정에 따라 일반적으로 CPU 수와 같거나 CPU의 2배입니다.
error_log 로그/error.log;
error_log 로그/error.log 공지;
error_log 로그/error.log 정보
오류 로그: 저장 경로.
pid log/nginx.pid;
pid(프로세스 식별자): 저장 경로.
worker_rlimit_nofile 204800
프로세스가 열 수 있는 최대 설명자 수를 지정합니다.
이 명령은 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에는 지정되지 않습니다.
추가 참고 사항:
apache와 유사하게 nginx는 운영 체제마다 다른 이벤트 모델을 갖습니다.
A) 표준 이벤트 모델
현재 시스템이 존재하지 않는 경우 표준 이벤트 모델을 선택하고 폴링합니다. 더 효율적인 방법인 nginx는 선택 또는 폴링을 선택합니다
B) 효율적인 이벤트 모델
Kqueue: FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 및 MacOS X에서 사용됩니다. 듀얼 프로세서를 사용하는 MacOS X 시스템은 kqueue를 사용합니다. 커널 충돌.
Epoll: Linux 커널 버전 2.6 이상의 시스템에서 사용됩니다.
/dev/poll: Solaris 7 11/99+, HP/UX 11.22+(이벤트 포트), IRIX 6.5.15+ 및 Tru64 UNIX 5.1A+에서 사용됩니다.
이벤트 포트: Solaris 10에서 사용됩니다. 커널 충돌을 방지하려면 보안 패치를 설치해야 합니다.
worker_connections 204800;
작업자 프로세스당 최대 연결 수입니다. 하드웨어에 맞게 조정하고 이전 작업 프로세스와 연계하여 사용하십시오. 가능한 한 크게 만들되 CPU를 100%로 실행하지 마십시오. 프로세스당 허용되는 최대 연결 수는 이론적으로 nginx 서버당 최대 연결 수입니다. Worker_processes*worker_connections
keepalive_timeout 60
keepalive 시간 초과.
client_header_buffer_size 4k;
클라이언트 요청 헤더의 버퍼 크기입니다. 이는 시스템 페이징 크기에 따라 설정될 수 있습니다. 일반적으로 요청 헤더의 크기는 1k를 초과하지 않습니다. 그러나 시스템 페이징은 일반적으로 1k보다 크므로 페이징 크기는 여기에서 설정됩니다.
페이징 크기는 getconf PAGESIZE 명령을 사용하여 얻을 수 있습니다.
[root@web001 ~]# getconf PAGESIZE
4096
그러나 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 유형을 설정하고 Defined를 입력합니다. mime.type 파일
default_type 애플리케이션/옥텟-스트림
log_format main '$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.loglog404;
log_format 지시어를 사용하여 로그 형식을 설정한 후 access_log 지시어를 사용해야 합니다. 로그 파일의 저장 경로를 지정합니다.
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;
이 지시어는 캐시 활성화 여부를 지정합니다.
예: open_file_cache max=1000 inactive=20s;
open_file_cache_min_uses 2;
open_file_cache_errors
구문: open_file_cache_errors | 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 이 지시어는 값을 지정합니다. in open_file_cache 명령어의 유효하지 않은 매개변수에서 특정 시간 범위 내에서 사용할 수 있는 최소 파일 수입니다. 더 큰 값을 사용하면
open_file_cache_valid
파일 디스크립터가 항상 열려 있습니다. 구문: open_file_cache_valid 시간 기본값: open_file_cache_valid 60 사용 필드: http, 서버, 위치 이 지시어는 open_file_cache에 캐시된 항목의 유효한 정보를 확인해야 하는 시기를 지정합니다.
client_max_body_size 300m
업로드되는 파일의 크기를 설정합니다. through nginx
sendfile on
sendfile 지시어는 nginx가 파일 출력을 위해 sendfile 함수(제로 복사 모드)를 호출할지 여부를 지정합니다. 다운로드와 같이 디스크 IO 로드가 많은 애플리케이션에 사용되는 경우 디스크와 네트워크 IO 처리 속도의 균형을 맞추고 시스템 가동 시간을 줄이기 위해 끄기로 설정할 수 있습니다.
tcp_nopush on;
이 옵션은 소켓 사용의 TCP_CORK 옵션을 허용하거나 비활성화합니다.
proxy_connect_timeout 90
백엔드 서버 연결 시작 시간 초과 응답 timeout
proxy_read_timeout 180
연결 성공 후 백엔드 서버가 응답하기를 기다리는 시간_실제로 처리를 기다리는 백엔드 큐에 들어갔습니다(백엔드 서버가 응답하는 시간이라고도 할 수 있음). -end 서버가 요청을 처리함)
proxy_send_timeout 180;
백엔드 서버 데이터 반환 시간_즉, 백엔드 서버는 지정된 시간 내에 모든 데이터를 전송해야 합니다.
proxy_buffer_size 256k>첫 번째 버퍼를 설정합니다. 프록시 서버에서 읽은 응답의 일부 영역 크기 일반적으로 응답의 이 부분에는 작은 응답 헤더가 포함됩니다. 기본적으로 이 값의 크기는 Proxy_buffers 지시문에 지정된 버퍼의 크기이지만 설정할 수 있습니다. 더 작게
proxy_buffers 4 256k ;
프록시 서버에서 응답을 읽는 데 사용되는 버퍼의 수와 크기를 설정합니다. 기본값은 또한 운영 체제에 따라 4k 또는 8k일 수 있습니다. 🎜>proxy_busy_buffers_size 256k;
proxy_temp_file_write_size 256k;
파일을 전달할 때 작업자 프로세스가 너무 오랫동안 차단되는 것을 방지하기 위해 Proxy_temp_path를 작성할 때 데이터 크기를 설정합니다. byproxy_temp_path 및 Proxy_cache_path는 동일한 파티션에 있어야 합니다.
proxy_cache_path /data0/proxy_cache_dirlevels=1:2keys_zone=cache_one:200m inactive=1d max_size=30g;
#메모리 캐시 공간 크기를 200MB로 설정합니다. 1일 동안 접속하지 않은 내용은 자동으로 지워지며, 하드디스크 캐시 공간 크기는 30GB입니다.
keepalive_timeout 120
keepalive 시간 초과.
tcp_nodelay on;
client_body_buffer_size 512k;
256k와 같이 비교적 큰 값으로 설정하면 256k보다 작은 이미지를 제출하기 위해 Firefox나 IE 브라우저를 사용하는 것이 정상입니다. 이 지시문을 주석 처리하고 운영 체제 페이지 크기(8k 또는 16k)의 두 배인 기본 client_body_buffer_size 설정을 사용하면 문제가 발생합니다.
firefox4.0을 사용하든 IE8.0을 사용하든 약 200k의 비교적 큰 이미지를 제출하면 500 내부 서버 오류가 반환됩니다.
proxy_intercept_errors on
은 nginx가 HTTP 응답 코드가 400 이상이 되지 않도록 하는 것을 의미합니다. 높은 반응.
업스트림 베이켄드 {
서버 127.0.0.1:8028;
서버 127.0.0.1:8029; nginx의 업스트림은 현재 4가지 할당 방법을 지원합니다
1. 폴링(기본값)
각 요청은 시간순으로 하나씩 다른 백엔드 서버에 할당됩니다. 백엔드 서버가 다운되면 자동으로 할당될 수 있습니다. 제거되었습니다.
2. 가중치
는 폴링 확률을 지정하며, 백엔드 서버 성능이 고르지 않을 때 사용됩니다.
예:
upstream bayend {
server 192.168.0.14 Weight=10;
server 192.168.0.15 Weight=10;
}
2, ip_hash
각 요청 누르기 접속 IP의 해시 결과를 할당하여 각 방문자가 백엔드 서버에 고정된 접속 권한을 갖도록 하여 세션 문제를 해결할 수 있습니다.
예:
upstream bayend {
ip_hash;
server 192.168.0.14:88;
server 192.168.0.15:80;
}
3. )
백엔드 서버의 응답 시간을 기준으로 요청이 할당되며, 응답 시간이 짧은 요청이 우선적으로 할당됩니다.
업스트림 백엔드 {
server server1;
server server2;
fair;
}
4. url_hash(타사)
접속된 해시 결과에 따라 요청을 분배합니다. url, 각 URL을 동일한 백엔드 서버로 지정하는 것이 백엔드 서버를 캐시할 때 더 효과적입니다.
예: 업스트림에 해시 문을 추가합니다. 가중치와 같은 다른 매개변수는 서버 문에 쓸 수 없습니다.
업스트림 백엔드 {
server squid1:3128;
server. squid2: 3128;
hash $request_uri;
hash_method crc32;
}
팁:
업스트림 Bakend{#로드 밸런싱 장치의 IP 및 장치 상태 정의}{
ip_hash ;
서버 127.0.0.1:9090 다운;
서버 127.0.0.1:8080 무게=2;
서버 127.0.0.1:6060;
서버 127.0.0.1:7070 백업;
}
로드 밸런싱을 사용해야 하는 서버에
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는 기록된 파일의 디렉터리를
설정할 수 있습니다. URL과 일치하고 리디렉션될 수 있습니다.
## 가상 머신 구성
서버
{
listen 80
수신 포트 구성
server_name 이미지.* **.com;
액세스 도메인 이름 구성
위치 ~* .(mp3|exe)$ {
"mp3 또는 exe"로 끝나는 로드 밸런싱 주소
proxy_pass http://img_relay$request_uri ;
으로 설정 프록시 서버의 포트 또는 소켓 및 URL
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr; ;
위 세 줄은 프록시 서버에서 받은 사용자 정보를 실제 서버로 전달하는 것이 목적입니다
}
location /face {
if ($http_user_agent ~* "xnp") {
^(.*) $ http://211.151.188.190:8080/face.jpg 리디렉션;
}
proxy_pass http://img_relay$request_uri
proxy_set_header 호스트 $host;
proxy_set_header X-Real-IP $ remote_addr;
proxy_set_header 🎜>다시 쓰기 ^(.*)$ http://211.151.188.190:8080/face.jpg 리디렉션
}
위치/이미지 {
if ($http_user_agent ~* "xnp") {
^(.*)$ http://211.151.188.190:8080/face.jpg 리디렉션
}
proxy_pass http: //img_relay$request_uri;
proxy_set_header 호스트 $host;
proxy_set_header X-Remote_addr;
proxy_set_headerlogs/image.loglog404>rewrite ^(.*)$ http:/ /211.151.188.190:8080/face.jpg 리디렉션;
}
}
##다른 예
서버
{
청취 80; .com *.***.cn;
위치 ~* .(mp3|exe)$ {
proxy_pass http: //img_relay$request_uri;
proxy_set_header 호스트 $host
proxy_set_header X- 실제 IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; >if ($http_user_agent ~* "xnp") {
^(.*)$ http://i1.***img .com/help/noimg.gif 리디렉션
}
proxy_pass http://img_relay$request_uri;
proxy_set_header 호스트 $host; X-Forwarded-For $proxy_add_x_forwarded_for;
#error_page 404 http:// i1.***img.com/help/noimg.gif;
error_page 404 502 = @fetch; 위치 @fetch {
access_log /data/logs/baijiaqi.log log404;
다시 쓰기 ^(.*)$ http://i1.***img.com/help/noimg.gif 리디렉션; >}
}
서버
{
듣기 80;
서버_이름 *.***img.com
위치 ~* .(mp3|exe)$ {
Proxy_pass http://img_relay$request_uri;
proxy_set_header 호스트 $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header 다시 쓰기 ^(.*)$ http://i1.***img .com/help/noimg.gif;
}
proxy_pass http://img_relay$request_uri;
proxy_set_header 호스트 $host
proxy_set_header
proxy_set_header; >error_page 404 = @fetch;
}
#access_log off;
location @fetch {
access_log /data/logs/baijiaqi.log log404>rewrite ^(.*)$ http ://i1.***img.com/help/noimg.gif 리디렉션
}
}
서버
{
listen 8080;
server_name ngx-ha. **img.com;
stub_status on;
}
}
server {
server_name imgsrc1. **.net;
루트 html; /local/nginx/logs/access_log main;
위치 / {
다시 쓰기 ^(.*)$ http://www.***.com/
}
}
서버 {
듣기 80;
server_name *******.com w.**********.com
# access_log /usr/local/nginx/logs/ access_log 메인 ;
위치 / {
다시 쓰기 ^(.*)$ http://www.*******.com/
}
}
서버 {
수신 80;
server_name ******.com;
# access_log /usr/local/nginx/logs/access_log main;
location / {
rewrite ^(.*) $ http ://www.********.com/;
}
}
위치 /NginxStatus {
stub_status on;
access_log on;
auth_basic "NginxStatus ";
auth_basic_user_file conf/htpasswd;
}
#Nginx 상태를 볼 수 있는 주소 설정
location ~ /.ht {
deny all;
}
#접근 불가 .htxxx 파일
}
참고: 변수
Ngx_http_core_module 모듈은 내장 변수를 지원하며 해당 이름은 Apache의 내장 변수와 일치합니다.
첫 번째는 $http_user_agent, $http_cookie 등 고객 요청 제목의 줄을 설명하는 것입니다.
이외에도 몇 가지 변수가 있습니다.
$args 이 변수는 요청 라인의 매개변수와 같습니다.
$content_length는 요청 라인의 "Content_Length" 값과 같습니다.
$content_type은 요청 헤더의 "Content_Type" 값과 같습니다.
$document_root는 현재 요청의 루트 지시문에 지정된 값과 같습니다.
$document_uri는 $uri와 같습니다
$host는 요청 헤더와 동일합니다. "Host" 행에 지정된 값은 요청이 도달하는 서버의 이름과 동일합니다(Host 행 제외)
$limit_rate는 제한된 연결 속도를 허용합니다
$request_method는 요청 방법과 동일하며 일반적으로 "GET" 또는 "POST"입니다.
$remote_addr 클라이언트 IP
$remote_port 클라이언트 포트
$remote_user는 ngx_http_auth_basic_module에서 인증된 사용자 이름과 동일합니다.
$request_filename 루트 또는 별칭 및 URI 요청으로 지정된 현재 요청된 파일의 경로 이름 결합
$request_body_file
$request_uri에는 매개변수의 전체 초기 URI가 포함됩니다.
$query_string은 $args와 동일합니다.
$sheeme http 모드(http, https)는 평가만 필요합니다.
Rewrite ^(.+)$ $sheme://example.com$; "HTTP/ 또는 "HTTP/를 사용하여 요청
$server_addr 요청이 도달한 서버의 IP입니다. 이 변수의 값을 얻는 일반적인 목적은 시스템 호출을 만드는 것입니다. 시스템 호출을 방지하려면 Listen 명령에 IP를 지정하고 바인드 매개변수를 사용해야 합니다.
$server_name 요청으로 도달한 서버 이름
$server_port 요청으로 도달한 서버의 포트 번호
$uri는 현재 요청의 URI와 동일하며 초기 값과 다를 수 있습니다. , 내부 리디렉션 또는 인덱스 사용
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
