>백엔드 개발 >PHP 문제 >nginx가 PHP 프로세스를 찾을 수 없으면 어떻게 해야 합니까?

nginx가 PHP 프로세스를 찾을 수 없으면 어떻게 해야 합니까?

藏色散人
藏色散人원래의
2021-07-19 10:56:212467검색

nginx가 PHP 프로세스를 찾을 수 없는 이유에 대한 해결 방법: 1. nginx.conf 구성을 수정합니다. 2. try_files를 사용하여 존재하지 않는 URL을 캡처하고 오류를 반환합니다.

nginx가 PHP 프로세스를 찾을 수 없으면 어떻게 해야 합니까?

이 기사의 운영 환경: windows7 시스템, PHP7.1 버전, DELL G3 컴퓨터

nginx PHP 프로세스를 찾을 수 없으면 어떻게 해야 합니까?

nginx에서 PHP 파일을 찾을 수 없습니다

php-fpm을 사용하여 PHP를 구문 분석하세요. "지정된 입력 파일 없음" 및 "파일을 찾을 수 없음"은 새로운 nginx 사용자에게 문제를 일으키는 일반적인 오류입니다. 실행할 SCRIPT_FILENAME 구성을 찾을 수 없습니다. php-fpm은 nginx에 기본 404 오류 프롬프트를 반환합니다.

예를 들어 내 웹 사이트에는 document_root 아래에 test.php가 없습니다. 이 파일에 액세스하면 패킷을 캡처하여 반환된 내용을 볼 수 있습니다.

HTTP/1.1 404 Not Found
Date: Fri, 21 Dec 2012 08:15:28 GMT
Content-Type: text/html
Proxy-Connection: close
Server: nginx/1.2.5
X-Powered-By: PHP/5.4.7
Via: 1.1 c3300 (NetCache NetApp/6.0.7)
Content-Length: 16
File not found.

많은 사람들이 사용자가 이 기본 404 오류 메시지를 직접 보는 것을 원하지 않고 404 오류를 사용자 정의하고 싶어합니다.

솔루션을 제공하기 전에 먼저 이러한 유형의 404 오류를 방지하는 방법을 분석해 보겠습니다. 그런 다음 사용자 정의 404 오류 페이지가 표시될 수 있도록 이러한 상황(예: 사용자가 존재하지 않는 잘못된 경로를 입력함)에 직면했을 때 어떻게 해야 하는지 진실을 알려줍니다.

1. 잘못된 경로가 php-fpm 프로세스로 전송됩니다

이런 종류의 오류가 발생하면 10개 중 9개의 경우는 백엔드 fastcgi 프로세스가 잘못된 경로(SCRIPT_FILENAME)를 수신하여 발생하며, 주된 이유는 다음과 같습니다. 백엔드 fastcgi가 잘못된 경로를 수신하는 이유는 구성 오류입니다.

일반적인 nginx.conf 구성은 다음과 같습니다.

server {
    listen   [::]:80;
    server_name  example.com www.example.com;
    access_log  /var/www/logs/example.com.access.log;  
    location / {
        root   /var/www/example.com;
        index  index.html index.htm index.pl;
    }
    location /images {
        autoindex on;
    }
    location ~ \.php$ {
        fastcgi_pass   127.0.0.1:9000;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME  /var/www/example.com$fastcgi_script_name;
        include fastcgi_params;
    }
}

이 구성에는 불합리한 점이 많습니다. 명백한 문제 중 하나는 루트 지시문이 위치/블록에 배치된다는 것입니다. 루트 지시문이 위치 블록에 정의된 경우 루트 지시문은 해당 위치에서만 적용될 수 있습니다. 예를 들어, location /images 블록은 어떤 요청과도 일치하지 않습니다. 이 문제를 해결하려면 각 요청에서 루트 지시문을 반복적으로 구성해야 합니다. 따라서 각 위치가 상위 서버 블록에서 정의한 documentroot를 상속하도록 root 지시어를 server 블록에 넣어야 합니다. 위치가 다른 document_root를 정의해야 하는 경우 해당 위치에 별도의 root 지시어를 정의할 수 있습니다.

또 다른 문제는 fastCGI 매개변수 SCRIPT_FILENAME이 하드 코딩되어 있다는 것입니다. 루트 지시문의 값을 수정하거나 파일을 다른 디렉터리로 이동하면 php-fpm은 "No input file selected" 오류를 반환합니다. 왜냐하면 SCRIPT_FILENAME이 구성에 하드 코딩되어 있고 $document_root가 변경되어도 변경되지 않기 때문입니다. SCRIPT_FILENAME은 다음과 같이 구성됩니다:

fastcgi_param  SCRIPT_FILENAME  documentrootfastcgi_script_name;

따라서 서버 블록에서 루트 지시어를 구성하는 것을 잊을 수 없습니다. 그렇지 않으면 documentroot의 값이 비어 있고 fastcgi_script_name만 php-fpm에 전달됩니다. "지정된 입력 파일 없음" 오류가 발생합니다.

2. 요청한 파일이 실제로 존재하지 않습니다.

nginx가 존재하지 않는 .php 파일에 대한 요청을 받으면 nginx는 $uri가 .php로 끝나는지만 확인하고 파일이 존재하는지 판단하지 않기 때문입니다. . .php nginx로 끝나는 요청은 처리를 위해 php-fpm으로 직접 전송됩니다. php-fpm 처리 중에 파일을 찾을 수 없으면 "404 Not Found" 헤더와 함께 "지정된 입력 파일 없음"이 반환됩니다.

해결책

우리는 nginx에서 존재하지 않는 파일을 가로채서 사용자 정의 404 오류를 요청하고 반환합니다.

try_files를 사용하여 존재하지 않는 URL을 캡처하고 오류를 반환합니다.

location ~ .php$ {
 try_files $uri =404;
 fastcgi_pass 127.0.0.1:9000;
 fastcgi_index index.php;
 fastcgi_param SCRIPT_FILENAME ....
 ...................................
 ...................................
}

위 구성은 .php 파일이 존재하는지 확인합니다. 존재하지 않으면 404 페이지가 반환됩니다.

추천 학습: "PHP 비디오 튜토리얼"

위 내용은 nginx가 PHP 프로세스를 찾을 수 없으면 어떻게 해야 합니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!

성명:
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.