Nginx + PHP를 올바르게 구성하는 방법

많은 사람들에게 Nginx+PHP를 구성하는 것은 튜토리얼을 검색한 다음 복사하여 붙여넣는 것 이상입니다. 별거 아닌 것 같지만 실제로는 인터넷에 떠도는 정보 중 상당수가 훼손되고 허점으로 가득 차 있다. 깊은 이해를 구하지 않고 그냥 복사해서 붙여넣기만 하면 조만간 대가를 치르게 될 것이다. .

PHP를 사용하여 프런트엔드 컨트롤러를 구현하거나, 직설적으로 말하면 통합 입구를 구현한다고 가정해 보겠습니다. 모든 PHP 요청을 동일한 파일로 보낸 다음 이 파일의 "REQUEST_URI"를 구문 분석하여 라우팅을 구현합니다.

일반적으로 다음과 같이 구성됩니다.
이때 많은 튜토리얼에서 Nginx+PHP를 다음과 같이 구성하도록 가르칩니다.

server {
  listen 80;
  server_name foo.com;
 
  root /path;
 
  location / {
    index index.html index.htm index.php;
 
    if (!-e $request_filename) {
      rewrite . /index.php last;
    }
  }
 
  location ~ /.php$ {
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME /path$fastcgi_script_name;
    fastcgi_pass 127.0.0.1:9000;
    fastcgi_index index.php;
  }
}

오류가 많거나 최소한 악취가 나는 경우도 있으니 잘 살펴보면 몇 가지를 찾을 수 있습니다.
먼저 Nginx 구성 파일에 있는 명령의 상속 관계를 이해해야 합니다.
Nginx 구성 파일은 외부에서 내부로 공통되는 블록은 "http", "server", "location" 등입니다. ., 기본값 상속 관계는 외부에서 내부로 이루어집니다. 즉, 내부 블록이 자동으로 외부 블록의 값을 기본값으로 가져옵니다.

"index" 명령부터 시작해 보겠습니다.
문제 구성에서는 "location"에 정의되어 있습니다.

location / {
  index index.html index.htm index.php;
}

나중에 새로운 "location"을 추가해야 하면 필연적으로 " index" 명령입니다. 이는 여러 "위치"가 수평 관계를 가지며 상속이 없기 때문입니다. 이때 "index"는 "server"에 정의되어야 합니다. 상속 관계를 사용하면 "index" 명령을 다음에서 사용할 수 있습니다. 모든 "위치"가 적용됩니다.

"if" 명령을 살펴보겠습니다
가장 오해받는 Nginx 명령이라고 해도 과언이 아닙니다:

if (!-e $request_filename) {
  rewrite . /index.php last;
}

많은 사람들이 "if" 명령을 사용하여 일련의 확인을 하는 것을 좋아하지만, 이것은 실제로는 "try_files"입니다. "명령의 책임:
try_files $uri $uri/ /index.php;
또한 초보자는 "if" 명령이 커널 수준 명령이라고 생각하는 경우가 많지만 실제로는 일부입니다. Nginx 구성은 실제로 절차적이라기보다는 선언적이므로 재작성되지 않는 모듈의 지시문과 혼합하면 결과가 원하는 것과 다를 수 있습니다.

"fastcgi_params" 구성 파일을 살펴보겠습니다.
include fastcgi_params;
Nginx에는 "fastcgi_params"와 "fastcgi.conf"라는 두 개의 fastcgi 구성 파일이 있다는 점만 다릅니다. 후자는 "SCRIPT_FILENAME"의 추가 정의 줄을 가집니다:
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name
참고: $document_root와 $fastcgi_script_name 사이에는 /가 없습니다.
원래 Nginx에는 "fastcgi_params"만 있었는데 나중에 많은 사람들이 "SCRIPT_FILENAME"을 정의할 때 하드 코딩을 사용한다는 사실이 밝혀져 사용법을 표준화하기 위해 "fastcgi.conf"가 도입되었습니다.
그러나 이는 질문을 제기합니다. 왜 이전 구성 파일을 수정하는 대신 새 구성 파일을 도입해야 합니까? 이는 "fastcgi_param" 명령어가 일반 명령어와 동일하기 때문입니다. 즉, 동일한 레벨에서 여러 번 사용될 경우 내부 레이어가 외부 레이어 대신 추가된다는 점입니다. 교체되었습니다. 즉, "SCRIPT_FILENAME"이 동일한 레벨에서 두 번 정의되면 둘 다 백엔드로 전송되므로 잠재적인 문제가 발생할 수 있으므로 이러한 상황을 방지하기 위해 새로운 구성 파일이 도입되었습니다.
또한 보안 문제도 고려해야 합니다. PHP가 "cgi.fix_pathinfo"를 활성화하면 PHP가 잘못된 파일 형식을 PHP 파일로 구문 분석할 수 있습니다. Nginx와 PHP가 동일한 서버에 설치된 경우 가장 간단한 해결 방법은 "try_files" 명령을 사용하여 다음을 필터링하는 것입니다.
try_files $uri =404;
개선된 버전
이전 분석에 따르면 향상된 버전이 아닌가요? 원본 버전보다 훨씬 깔끔함:

server {
  listen 80;
  server_name foo.com;
 
  root /path;
  index index.html index.htm index.php;
 
  location / {
    try_files $uri $uri/ /index.php$is_args$args;
  }
 
  location ~ /.php$ {
    try_files $uri =404;
 
    include fastcgi.conf;
    fastcgi_pass 127.0.0.1:9000;
  }
}

위 내용은 이 글의 전체 내용입니다. 모든 분들의 학습에 도움이 되기를 바라며, 모두가 Script Home을 응원해 주시길 바랍니다.