Nginx + php5-fpm = Không tìm thấy tập tin

Tôi đã va vào tường trong khi thiết lập trang web bằng nginx / fpm. Trang hiển thị "Không tìm thấy tệp" và điều này xuất hiện trong lỗi nginx.log:

FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream

Tôi mới sử dụng cả nginx và fpm và thông báo lỗi đó không có nghĩa gì với tôi (ngay cả máy google cũng không giúp được gì!). Bất cứ ai có thể làm sáng tỏ những gì có thể xảy ra?

Bạn nên có một locationphần để xử lý các yêu cầu PHP được cấu hình tương tự như sau:

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

(Phần bổ sung try_filesgiải quyết lỗ hổng bảo mật có thể cho phép các tệp tùy ý được thực thi dưới dạng PHP.)

Bên cạnh đó, bạn rootnên được xác định trong serverphần của tập tin cấu hình, không những locationphần. Đây là một trong những cấu hình sai nginx phổ biến nhất .

Đây là một lưu ý cho cài đặt hành khách.

Tôi vừa cài đặt nginx từ nguồn thông qua hành khách, điều này gây ra sự cố với php5-fpm. Nginx.conf mặc định sử dụng vấn đề được mô tả bởi Michael Hampton. Giải pháp là loại bỏ các blok xung quanh các chỉ thị gốc và chỉ mục, vì vậy:

location / {
    root html
    index index.html index.htm
}

trở thành:

root html
index index.html index.htm

Hơn nữa, khối php được thiết lập không chính xác. Xem câu trả lời của Michael Hamptons cho cách chính xác.

Một lưu ý bổ sung có thể là nếu php5-fpm được thiết lập để sử dụng socket chỉ tham số fastcgi_pass trong khối php trong nginx.conf vào thiết lập socket trong /etc/php5/fpm/pool.d/www.conf.

Tôi vừa gặp vấn đề này trong một phiên bản mới của nginx. (cấu hình được lấy từ phiên bản cũ hơn)

Những gì tôi phải làm là đặt các include fastcgi_params;tùy chỉnh ở trên của tôi SCRIPT_FILENAMEnhư thế này:

location @web {
        try_files $uri =404;
        include         fastcgi_params;
        fastcgi_pass    127.0.0.1:9000;
        fastcgi_param   SCRIPT_FILENAME  $document_root/index.php;
}

Như SCRIPT_FILENAMEđã được ghi đè.

Nếu bạn đang sử dụng các bí danh trong các khối vị trí của mình, một lỗi 404 chưa được xử lý cũng có thể thể hiện hành vi này. Bạn có thể thấy điều này nếu trang hiển thị trong trình duyệt là văn bản đơn giản "Không tìm thấy tệp" trái ngược với trang nginx 404 được định dạng (ở giữa) đẹp hơn. Về cơ bản, nó thực sự nói rằng trang 404 không thể được tìm thấy.

Để giải quyết, hãy thêm một try_files $uri =404dòng bổ sung trong khối vị trí của bạn và tải lại cấu hình nginx. Ngoài những gì Michael Hampton nói về việc giải quyết một lỗ hổng bảo mật cụ thể , điều này cũng cho phép trình xử lý fastcgi ghi đè định nghĩa bí danh và tìm tập lệnh 404 ở vị trí mặc định.

sudo vim /etc/php-fpm.conf

về dòng 149, thay đổi người dùng php && nhóm người dùng

Tôi kiểm tra nó thành công bây giờ.

Tôi đã từng thấy :

FastCGI được gửi trong stderr: "Không biết tập lệnh chính" trong khi đọc tiêu đề phản hồi từ thượng nguồn

trong một máy chủ tôi đặt dưới tải cao khi kiểm tra căng thẳng. Sự nghi ngờ của tôi, vẫn còn được xác nhận, là các tệp xử lý có sẵn từ HĐH đã cạn kiệt. Trong trường hợp đó, php-fpm không thể có được tham chiếu đến tệp.

Tôi nhận ra đây là suy đoán nhưng nó chắc chắn phù hợp với kịch bản của tôi và cũng có thể giúp đỡ người khác.

Cảm ơn @homeway, câu trả lời của bạn truyền cảm hứng cho tôi. Cảm ơn rât nhiều!

Tôi gặp cùng một câu hỏi, nhưng phương pháp khác không giúp tôi giải quyết câu hỏi!

Tôi giải quyết nó, tôi thấy điểm mấu chốt là: Người dùng Linux phải dẫn đến câu hỏi: FastCGI được gửi trong stderr: "Không biết tập lệnh chính"

Bởi vì người dùng mặc định PHP-FPM: nhóm là apache: apache, nhưng mã dir của bạn là someBody: someBody. Vì vậy, bạn nên thay đổi người dùng ngay!

Tôi viết một blog để giải quyết câu hỏi này, Bạn có thể xem blog này:

[Nginx FastCGI được gửi trong stderr: "Không biết tập lệnh chính"] [1] `[1]: http://geekhades.blogspot.com/2017/06/nginx-fastcgi-sent-in-stderr-primary.html