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

이 글은 주로 Nginx + PHP 구성 단계를 자세히 소개하고, 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"를 정의해야 합니다. , "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;
  }
}

관련 권장 사항:

nginx는 PHP 스크립트를 구문 분석할 수 없습니다.

위 내용은 Nginx + PHP를 올바르게 구성하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!