nginx에서 PHP를 설정하는 방법: 먼저 Nginx에서 fastcgi_params 및 fastcgi.conf 구성 파일을 수정한 다음 PHP에서 cgi.fix_pathinfo가 켜져 있을 때 try_files 명령을 사용하여 한 번 필터링합니다.
권장: "PHP 비디오 튜토리얼"
이 튜토리얼의 운영 환경: Linux5.9.8 시스템, PHP7.1 버전 이 방법은 모든 브랜드의 컴퓨터에 적합합니다.
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" 명령은 "서버"에 정의되어야 합니다. 모든 "위치" 모두 유효합니다.
…
가장 오해받는 Nginx 명령어라고 해도 과언이 아닌 “if” 명령을 살펴보겠습니다.
if (!-e $request_filename) { rewrite . /index.php last; }
많은 사람들이 “if” 명령을 사용하여 일련의 작업을 수행하는 것을 좋아합니다. 확인하지만 실제로는 "try_files" 명령어의 책임입니다:
try_files $uri $uri/ /index.php;
또한 초보자는 종종 "if" 명령어가 커널 수준 명령어라고 생각하지만 실제로는 rewrite 모듈의 일부입니다. 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; } }
사실 여전히 몇 가지 결함이 있습니다. 주로 "try_files"와 "fastcgi_split_path_info"가 충분히 호환되지 않기 때문입니다. 해결할 수는 있지만 해결책이 보기 흉하므로 자세히 설명하지 않겠습니다.
추가: "위치"가 제한되어 있으므로 "fastcgi_index"는 실제로 필요하지 않습니다.
위 내용은 nginx에서 PHP를 설정하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!