nginx.conf 설정 파일에 대한 자세한 설명

엔진엑스 구성 파일은 크게 네 부분으로 나뉩니다. main(전역 설정), server(호스트 설정), upstream(업스트림 서버 설정, 주로 역방향 프록시, 부하 분산 관련 설정), location(URL이 특정 위치와 일치하는 경우의 설정)입니다. main 부분에 설정된 명령어는 다른 모든 부분의 설정에 영향을 미칩니다. server 부분의 명령어는 주로 가상 호스트 도메인 이름, IP 및 포트 번호를 설정하는 데 사용됩니다. upstream 부분의 명령어는 일련의 백엔드 서버를 설정하고, 역방향 프록시를 설정하고, 백엔드 서버의 부하 분산을 설정합니다. location 부분은 웹 페이지의 위치(예: 루트 디렉터리 "/", "/images" 등)를 일치시키는 데 사용됩니다. 이들 간의 관계는 다음과 같습니다. server는 main을 상속하고, location은 server를 상속합니다. upstream은 명령어를 상속하지도 상속받지도 않습니다.
nginx.conf 구성 파일
다음은 nginx.conf 설정 파일에 대한 자세한 설명입니다. (다음 설정 매개변수는 반드시 사용되는 것은 아니며, 설정 매개변수 설명을 위한 참조로만 사용됩니다. 아래에서 일반적인 버전 소개를 확인할 수 있습니다.)


#는 Nginx가 실행하는 사용자와 사용자 그룹을 정의합니다.
사용자 www www;

#nginx 프로세스 번호는 일반적으로 CPU 수와 동일하게 설정됩니다.
작업자 프로세스 4;

# 글로벌 오류 로그 정의 유형, [디버그 | 정보 | 알림 | 경고 | 오류 | 심각]
#error_log 로그/error.log;
#error_log 로그/error.log 알림;
#error_log 로그/error.log 정보;

# 프로세스 pid 파일
#pid 로그/nginx.pid;

#는 프로세스가 열 수 있는 설명자의 최대 수를 지정합니다.
# 작동 모드 및 연결 수의 상한
## 이 명령어는 nginx 프로세스가 열 수 있는 최대 파일 디스크립터 개수를 나타냅니다. 이론적인 값은 ulimit -n 명령어를 사용하여 열 수 있는 최대 파일 개수를 nginx 프로세스 개수로 나눈 값이어야 하지만, nginx는 요청을 균등하게 할당하지 않으므로 ulimit -n 명령어의 값과 동일하게 유지하는 것이 좋습니다.
# 이는 nginx가 스케줄링 과정에서 프로세스에 요청을 균등하게 할당하지 않기 때문입니다. 따라서 10240을 입력할 경우, 총 동시 접속자가 30,000~40,000에 도달하면 프로세스가 10240개를 초과할 수 있으며, 이 경우 502 오류가 반환됩니다.
작업자_rlimit_nofile 65535;

이벤트 {
# 참조 이벤트 모델, [kqueue | rtsig | epoll | /dev/poll | select | poll]을 사용합니다. epoll 모델
#는 Linux 커널 버전 2.6 이상에서 사용되는 고성능 네트워크 I/O 모델입니다. Linux는 epoll을 권장합니다. FreeBSD에서 실행하는 경우 kqueue 모델을 사용하세요.
# 추가 지침:
#는 Apache와 유사합니다. Nginx는 운영 체제에 따라 다른 이벤트 모델을 제공합니다.
#A) 표준 이벤트 모델
#Select와 poll은 표준 이벤트 모델에 속합니다. 현재 시스템에 더 효과적인 방법이 없다면 nginx는 select 또는 poll을 선택합니다.
#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+(eventport), IRIX 6.5.15+, Tru64 UNIX 5.1A+에서 사용됩니다.
#Eventport: Solaris 10에서 사용됩니다. 커널 충돌을 방지하려면 보안 패치를 설치해야 합니다.
epoll을 사용하세요

# 단일 프로세스에 대한 최대 연결 수(최대 연결 수 = 연결 수 + 프로세스 수)
#는 하드웨어에 맞게 조정되며 이전 작업 과정과 함께 사용됩니다. 가능한 한 크게 설정해야 하지만, 컵을 100%까지 늘리지 마십시오.
작업자 연결 1024;

#keepalive 타임아웃
keepalive_timeout 60;

# 클라이언트 요청 헤더 버퍼 크기입니다. 시스템 페이징 크기에 따라 설정할 수 있습니다. 일반적으로 요청 헤더 크기는 1KB를 초과하지 않습니다. 하지만 시스템 페이징 크기는 일반적으로 1KB보다 크기 때문에 여기에 설정된 페이징 크기로 설정됩니다.
# 페이징 크기는 getconf PAGESIZE 명령을 사용하여 얻을 수 있습니다.
#[root@web001 ~]# getconf 페이지 크기
# 그러나 client_header_buffer_size가 4k를 초과하는 경우가 있는데, 이때 client_header_buffer_size의 값을 "시스템 페이징 크기"의 정수 배수로 설정해야 합니다.
클라이언트 헤더 버퍼 크기 4k;

#는 열려 있는 파일에 대한 캐시를 지정합니다. 기본적으로 활성화되어 있지 않습니다. max는 캐시 개수를 지정합니다. 열려 있는 파일 개수와 동일하게 설정하는 것이 좋습니다. inactive는 파일을 요청하지 않으면 캐시가 삭제되는 시간을 나타냅니다.
open_file_cache 최대=65535 비활성=60초;

#는 캐시된 정보의 유효성을 검사하는 빈도를 나타냅니다.
# 구문: open_file_cache_valid time 기본값: open_file_cache_valid 60 사용 위치: http, server, location 이 지시어는 open_file_cache에 있는 캐시 항목의 유효성을 언제 검사할지 지정합니다.
open_file_cache_valid 80초;

#open_file_cache 지시어의 비활성 매개변수 time 내에 파일이 사용되는 최소 횟수입니다. 이 횟수를 초과하면 파일 설명자가 항상 캐시에서 열립니다. 예를 들어, 파일이 비활성 시간 내에 한 번도 사용되지 않으면 삭제됩니다.
# 구문: open_file_cache_min_uses number 기본값: open_file_cache_min_uses 1 범위: http, server, location 이 지시어는 open_file_cache 지시어가 유효하지 않을 때 특정 시간 내에 사용할 수 있는 최소 파일 개수를 지정합니다. 더 큰 값을 사용하면 파일 설명자가 캐시에서 항상 열려 있습니다.
오픈_파일_캐시_최소_사용_시간 1;

# 구문: open_file_cache_errors on | off 기본값: open_file_cache_errors off 컨텍스트: http, server, location 이 지시어는 파일을 검색할 때 캐시 오류를 기록할지 여부를 지정합니다.
open_file_cache_errors 켜짐;
}

#는 http 서버를 설정하고 역방향 프록시 기능을 사용하여 부하 분산 지원을 제공합니다.
http{
# 파일 확장자 및 파일 유형 매핑 테이블
mime.types를 포함합니다.

# 기본 파일 형식
기본 유형 애플리케이션/옥텟 스트림;

# 기본 인코딩
문자셋 utf-8;

# 서버 이름 해시 테이블 크기
#서버 이름을 저장하는 해시 테이블은 server_names_hash_max_size 및 server_names_hash_bucket_size 지시문에 의해 제어됩니다. 매개변수 해시 버킷 크기는 항상 해시 테이블 크기와 동일하며 프로세서 캐시 크기의 배수입니다. 이를 통해 프로세서에서 해시 테이블 키 조회 속도를 높이고 메모리 액세스 횟수를 줄일 수 있습니다. 해시 버킷 크기가 프로세서 캐시 크기와 같으면 키를 조회할 때 최악의 경우 메모리 조회 횟수는 2회입니다. 첫 번째는 저장 장치의 주소를 확인하는 것이고, 두 번째는 저장 장치에서 키 값을 찾는 것입니다. 따라서 Nginx가 해시 최대 크기 또는 해시 버킷 크기를 늘려야 한다는 힌트를 제공하면 가장 먼저 해야 할 일은 이전 매개변수의 크기를 늘리는 것입니다.
서버 이름 해시 버킷 크기 128;

# 클라이언트 요청 헤더의 버퍼 크기입니다. 시스템의 페이징 크기에 따라 설정할 수 있습니다. 일반적으로 요청 헤더의 크기는 1k를 초과하지 않습니다. 하지만 시스템 페이징 크기는 일반적으로 1k보다 크기 때문에 여기에 페이징 크기가 설정됩니다. 페이징 크기는 getconf PAGESIZE 명령을 사용하여 얻을 수 있습니다.
클라이언트_헤더_버퍼_크기 32k;

# 클라이언트 요청 헤더 버퍼 크기입니다. 기본적으로 nginx는 client_header_buffer_size 버퍼를 사용하여 헤더 값을 읽습니다. 헤더가 너무 크면 large_client_header_buffers 버퍼를 사용하여 읽습니다.
큰 클라이언트 헤더 버퍼 4 64k;

#는 nginx를 통해 업로드되는 파일의 크기를 설정합니다.
클라이언트_최대_신체_크기 8m;

sendfile 켜기; #는 효율적인 파일 전송 모드를 켭니다. sendfile 지시어는 nginx가 파일을 출력하기 위해 sendfile 함수를 호출할지 여부를 지정합니다. 일반적인 애플리케이션에서는 켜짐으로 설정됩니다. 다운로드 및 디스크 I/O 부하가 큰 기타 애플리케이션에 사용되는 경우, 디스크 및 네트워크 I/O 처리 속도의 균형을 맞추고 시스템 부하를 줄이기 위해 꺼짐으로 설정할 수 있습니다. 참고: 이미지가 정상적으로 표시되지 않으면 이 지시어를 꺼짐으로 변경하십시오.
#sendfile 지시어는 nginx가 파일을 출력하기 위해 sendfile 함수(제로 복사 모드)를 호출할지 여부를 지정합니다. 일반적인 애플리케이션에서는 이 지시어를 켜짐으로 설정해야 합니다. 다운로드와 같이 디스크 I/O 부하가 큰 애플리케이션에 사용되는 경우, 디스크 및 네트워크 I/O 처리 속도의 균형을 맞추고 시스템 가동 시간을 줄이기 위해 이 지시어를 꺼짐으로 설정할 수 있습니다.
sendfile 켜짐;

#는 다운로드 서버에 적합한 디렉토리 목록 액세스를 열고 기본적으로 닫힙니다.
자동인덱싱 켜짐;

# 이 옵션은 socke의 TCP_CORK 옵션 사용을 활성화 또는 비활성화합니다. 이 옵션은 sendfile을 사용할 때만 사용됩니다.
tcp_nopush 켜짐;

tcp_nodelay 켜짐;

# 긴 연결 시간 초과(초)
keepalive_timeout 120;

#FastCGI 관련 매개변수는 웹사이트 성능 향상을 위해 사용됩니다. 리소스 사용량을 줄이고 접속 속도를 높이는 것입니다. 다음 매개변수는 문자 그대로의 의미를 살펴보면 이해할 수 있습니다.
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
fastcgi_buffer_size 64k;
fastcgi_buffers 4 64k;
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; # 압축 레벨
gzip_types text/plain application/x-javascript text/css application/xml; # 압축 유형입니다. textml은 기본적으로 포함되어 있으므로 아래에 작성할 필요가 없습니다. 작성해도 문제는 없지만 경고가 표시됩니다.
gzip_vary 켜짐;

IP 연결 수를 제한할 때는 #를 사용해야 합니다.
#limit_zone 크롤러 $binary_remote_addr 10m;

# 부하 분산 구성
업스트림 piao.jd.com {

# 업스트림 로드 밸런싱에서 가중치는 머신 구성에 따라 정의될 수 있는 가중치입니다. 가중치 매개변수는 가중치를 나타내며, 가중치가 높을수록 할당될 확률이 높아집니다.
서버 192.168.80.121:80 가중치=3;
서버 192.168.80.122:80 가중치=2;
서버 192.168.80.123:80 가중치=3;

#nginx의 업스트림은 현재 4가지 유형의 배포를 지원합니다.
#1, 폴링(기본값)
# 각 요청은 시간 순서대로 하나씩 백엔드 서버에 할당됩니다. 백엔드 서버가 다운되면 자동으로 제거될 수 있습니다.
#2, 무게
#는 폴링 확률을 지정합니다. 가중치는 접근 비율에 비례하며 백엔드 서버 성능이 고르지 않을 때 사용됩니다.
#예를 들어:
#upstream 베이크엔드 {
# 서버 192.168.0.14 가중치=10;
# 서버 192.168.0.15 가중치=10;
#}
#2, ip_hash
# 각 요청은 액세스 IP의 해시 결과에 따라 할당되므로 각 방문자가 고정된 백엔드 서버에 액세스하여 세션 문제를 해결할 수 있습니다.
#예를 들어:
#upstream 베이크엔드 {
# ip_해시;
# 서버 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;
# 해시 $ 요청_uri;
# 해시 메서드 crc32;
#}

#팁:
#upstream bakend{#는 부하 분산 장치의 IP 및 장치 상태를 정의합니다.}{
# ip_해시;
# 서버 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.weight 무게가 클수록 하중의 무게도 커집니다.
#3.max_fails: 허용되는 기본 요청 실패 횟수는 1회입니다. 최대 횟수를 초과하면 proxy_next_upstream 모듈에서 정의한 오류가 반환됩니다.
#4.fail_timeout: max_fails 실패 후 일시 중지 시간.
#5.backup: 다른 모든 비백업 머신이 다운되거나 사용 중일 때 백업 머신이 요청됩니다. 따라서 이 머신의 부하가 가장 적습니다.

#nginx는 다양한 서버에서 사용할 수 있도록 여러 개의 부하 분산 그룹을 동시에 설정하는 것을 지원합니다.
#client_body_in_file_only는 클라이언트가 디버깅을 위해 파일에 게시한 데이터를 기록하기 위해 On으로 설정됩니다.
#client_body_temp_path는 레코드 파일의 디렉터리를 설정합니다. 최대 3단계까지 디렉터리를 설정할 수 있습니다.
#location은 URL과 일치합니다. 리디렉션하거나 새로운 프록시 부하 분산을 수행할 수 있습니다.
}

# 가상 호스트 구성
서버 {
# 수신 포트
듣기 80;

공백으로 구분된 여러 개의 # 도메인 이름이 있을 수 있습니다.
서버 이름 www.jd.com jd.com;
# 기본 항목 파일 이름
인덱스 index.html index.htm index.php;
루트 /data/www/jd;

#는 ******에서 로드 밸런싱을 수행합니다.
위치 ~ .*.(php|php5)?$
{
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi.conf를 포함합니다.
}

# 사진 캐시 시간 설정
위치 ~ .*.(gif|jpg|jpeg|png|bmp|swf)$
{
10일 만료
}

#JS 및 CSS 캐시 시간 설정
위치 ~ .*.(js|css)?$
{
1시간 후에 만료됩니다.
}

# 로그 형식 설정
#$remote_addr 및 $http_x_forwarded_for는 클라이언트의 IP 주소를 기록하는 데 사용됩니다.
#$remote_user: 클라이언트 사용자 이름을 기록하는 데 사용됩니다.
#$time_local: 접속 시간과 시간대를 기록하는 데 사용됩니다.
#$request: 요청된 URL과 http 프로토콜을 기록하는 데 사용됩니다.
#$status: 요청 상태를 기록하는 데 사용됩니다. 성공은 200입니다.
#$body_bytes_sent: 클라이언트에 전송된 파일 본문의 크기를 기록합니다.
#$http_referer: 방문이 온 페이지 링크를 기록하는 데 사용됩니다.
#$http_user_agent: 클라이언트 브라우저의 관련 정보를 기록합니다.
# 일반적으로 웹 서버는 리버스 프록시 뒤에 위치하므로 클라이언트의 IP 주소를 얻을 수 없습니다. $remote_add를 통해 얻은 IP 주소는 리버스 프록시 서버의 IP 주소입니다. 리버스 프록시 서버는 전달된 요청의 HTTP 헤더 정보에 x_forwarded_for 정보를 추가하여 원래 클라이언트의 IP 주소와 원래 클라이언트가 요청한 서버 주소를 기록할 수 있습니다.
log_format 액세스 '$remote_addr - $remote_user [$time_local] "$request" '
'$상태 $body_bytes_sent "$http_referer"'
'"$http_user_agent" $http_x_forwarded_for';

#는 이 가상 호스트의 액세스 로그를 정의합니다.
액세스_로그 /usr/local/nginx/logs/host.access.log 메인;
액세스_로그 /usr/local/nginx/logs/host.access.404.log log404;

# "/connect-controller"에 대한 역방향 프록시를 활성화합니다.
위치 /connect-controller {
proxy_pass http://127.0.0.1:88; #여기서 포트 번호는 가상 호스트가 수신하는 포트 번호(즉, 서버가 수신하는 포트)와 같을 수 없다는 점에 유의하세요.
proxy_redirect 꺼짐;
proxy_set_header X-Real-IP $remote_addr;

# 백엔드 웹 서버는 X-Forwarded-For를 통해 사용자의 실제 IP를 얻을 수 있습니다.
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

# 다음은 일부 역방향 프록시 구성이며 선택 사항입니다.
proxy_set_header 호스트 $host;

# 클라이언트가 요청할 수 있는 단일 파일의 최대 바이트 수
클라이언트_최대_신체_크기 10m;

# 프록시가 클라이언트 요청에 대해 버퍼링하는 최대 바이트 수입니다.
# 256k와 같이 비교적 큰 값으로 설정하면 Firefox나 IE 브라우저를 사용하여 256k보다 작은 이미지를 제출하더라도 정상적으로 작동합니다. 이 지시문에 주석을 달고 운영 체제 페이지 크기의 두 배인 기본 client_body_buffer_size 설정(8k 또는 16k)을 사용하면 문제가 발생합니다.
Firefox 4.0 또는 IE 8.0을 사용하든 약 200k의 비교적 큰 이미지를 제출하면 500 내부 서버 오류가 반환됩니다.
클라이언트_바디_버퍼_크기 128k;

#는 nginx에게 400 이상의 HTTP 응답 코드를 차단하라고 지시합니다.
proxy_intercept_errors 켜짐;

# 백엔드 서버 연결 시간 초과_핸드셰이크 시작 및 응답 대기 시간 초과
백엔드 서버와의 Nginx 연결 시간 초과(프록시 연결 시간 초과)
프록시_연결_시간 초과 90;

백엔드 서버 데이터 전송 시간(에이전트 전송 타임아웃)
# 백엔드 서버 데이터 전송 시간_은 백엔드 서버가 지정된 시간 내에 모든 데이터를 전송해야 함을 의미합니다.
프록시_전송_시간 초과 90;

연결이 성공한 후 백엔드 서버 응답 시간(프록시 수신 시간 초과)
#가 성공적으로 연결한 후 백엔드 서버의 응답을 기다리는 데 걸리는 시간은 실제로 처리를 기다리는 백엔드 대기열에 들어간 시간입니다(백엔드 서버가 요청을 처리하는 데 걸리는 시간이라고도 할 수 있습니다).
프록시_읽기_시간 초과 90;

#는 프록시 서버(nginx)에 사용자 헤더 정보를 저장하기 위한 버퍼 크기를 설정합니다.
#는 프록시 서버에서 읽은 응답의 첫 번째 부분에 대한 버퍼 크기를 설정합니다. 일반적으로 이 응답 부분에는 작은 응답 헤더가 포함됩니다. 기본적으로 이 값은 proxy_buffers 지시어에 지정된 버퍼 크기이지만, 더 작은 크기로 설정할 수 있습니다.
프록시 버퍼 크기 4k;

#proxy_buffers 버퍼, 평균 웹 페이지는 32k 이하로 설정됩니다.
#는 프록시 서버에서 응답을 읽는 데 사용되는 버퍼의 수와 크기를 설정합니다. 기본값은 페이징 크기이며, 운영 체제에 따라 4KB 또는 8KB가 될 수 있습니다.
프록시 버퍼 4 32k;

높은 부하 하에서 # 버퍼 크기(proxy_buffers*2)
프록시_비지_버퍼_크기 64k;

#는 파일을 전달할 때 작업자 프로세스가 너무 오랫동안 차단되는 것을 방지하기 위해 proxy_temp_path에 쓸 때 데이터 크기를 설정합니다.
# 캐시 폴더 크기를 설정합니다. 이 값보다 크면 업스트림 서버에서 전송됩니다.
프록시_임시_파일_쓰기_크기 64k;
}

# 로컬 동적 및 정적 분리 역방향 프록시 구성
# 모든 jsp 페이지는 tomcat 또는 resin에서 처리됩니다.
위치 ~ .(jsp|jspx|do)?$ {
proxy_set_header 호스트 $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
프록시_패스 http://127.0.0.1:8080;
}
}
}

Nginx 일반 구성 파일(Windows 시스템의 nginx1.14.2에 있는 nginx.conf 구성은 다음과 같습니다)
다음의 nginx.conf는 프런트 엔드에서 역방향 프록시 서버로 nginx를 구현하여 js 및 png와 같은 정적 파일을 처리하고 jsp와 같은 동적 요청을 다른 서버로 전달하는 예를 보여줍니다(관련 구성 매개변수에 대한 자세한 설명은 위 설명을 참조하세요).

작업자 프로세스 1;

#error_log 로그/error.log;
#error_log 로그/error.log 알림;
#error_log 로그/error.log 정보;

#pid 로그/nginx.pid;

이벤트 {
작업자 연결 1024;
}

http {
mime.types를 포함합니다.
기본 유형 애플리케이션/옥텟 스트림;

#log_format 메인 '$remote_addr - $remote_user [$time_local] "$request" '
# '$상태 $body_bytes_sent "$http_referer"'
# '"$http_user_agent" "$http_x_forwarded_for"';

access_log 로그/access.log 메인;
error_log 로그/ssl.error.log crit;

sendfile 켜짐;
#tcp_nopush 켜짐;

#keepalive_timeout 0;
keepalive_timeout 65;

#gzip 켜짐;

서버 {
듣기 8088;
서버 이름 로컬호스트;

문자셋 utf-8;

#access_log 로그/host.access.log 메인;

# 항목 파일 설정
위치 / {
루트 D:/vueWork/dentalFactory/dist; # 항목 파일 디렉토리
index index.html index.htm; # 기본 항목 파일 이름
}

# tomcat 역방향 프록시 구성
위치 /위치 이름/ {
proxy_pass http://192.168.1.10:8080; # http://127.0.0.1:8080/서비스 이름(프로젝트 이름)/
#proxy_set_header 호스트 $host;
proxy_set_header Host $host:$server_port; //참고: 현재 프로젝트의 포트 번호가 8080이 아닌 경우 이 구성이 필요합니다. 그렇지 않으면 백엔드가 올바른 포트 번호를 가져올 수 없습니다.
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

정적 리소스의 # 프록시 구성(일반적으로 구성이 필요하지 않음, 이미지 리소스 구성의 예는 다음과 같습니다)
#위치 /이미지/ {
# 루트 D:/A-studySpace/nginxDemo;
#}

1TP5404 페이지를 구성하는 곳입니다.
#error_페이지 404 /404.html;

# 요청 상태에 대한 해당 페이지 구성 위치입니다.
오류_페이지 500 502 503 504 /50x.html;
위치 = /50x.html {
루트 HTML;
}

# PHP 역방향 프록시 구성
#는 모든 php 페이지 요청을 php-fpm으로 전달하여 처리합니다.
#위치 ~ \.php$ {
# 루트 html;
# fastcgi_pass 127.0.0.1:9000;
# fastcgi_index index.php;
# fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name; #fastcgi_param에는 많은 구성 매개변수가 있으므로 필요에 따라 조정하세요.
#에는 fastcgi_params가 포함됩니다.
#}

}

# IP, 이름 및 포트 기반 구성을 혼합하여 사용하는 또 다른 가상 호스트
#
#서버 {
# 8000을 듣습니다.
# 듣기 somename:8080;
# 서버 이름 일부 이름 별칭 다른 별칭;

# 위치 / {
# 루트 html;
# 인덱스 index.html index.htm;
# }
#}

# HTTPS 서버
#
#서버 {
#는 443 ssl을 수신합니다.
# 서버 이름 로컬호스트;

# ssl_인증서 cert.pem;
# ssl_인증서_키 cert.key;

# ssl_session_cache 공유:SSL:1m;
# ssl_세션_타임아웃 5분;

# ssl_ciphers HIGH:!aNULL:!MD5;
# ssl_prefer_server_ciphers가 켜짐;

# 위치 / {
# 루트 html;
# 인덱스 index.html index.htm;
# }
#}

}