AuthorPostedbyThomas

Nginx with php-fpm generating blank page

I struggled a long time trying to figure out why my nginz + php-fpm setup was not working. I could tell that the gateway was fine and I was getting a HTTP 200 OK response, but the output was blank and there were no illuminating entries in either the nginx or php-fpm logs.

After a ton of research, I found the hint that I needed here:

https://bbs.archlinux.org/viewtopic.php?pid=903811#p903811

Essentially, I needed to set the SCRIPT_FILENAME param like so:

fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;

Php_fpm needs this so that it knows the path to the PHP file. You may need to set this param differently according to where you store your PHP files.

The default nginx setup I used includes a fastcgi_params file and a fastcgi.conf file. The fastcgi.conf file defines SCRIPT_FILENAME whereas the fastcgi_params does not. My guess is that the fastcgi.conf is not being used, which is why SCRIPT_FILENAME was not set.

♡

26 Comments

  1. avontz
    Permalink

    live saver =)

  2. Pete
    Permalink

    Thanks a bunch!

  3. Rodrigo Fonseca
    Permalink

    Thank you!

  5. Fix: Error opening wordpress and other php website after PHP upgrade | Cryptic Ideas
    at
  8. Martie
    Permalink

    After upgrading my (before correct working) Ubuntu Linux server i got this problem too 🙂
    Amazing, just added the SCRIPT_FILENAME line, restarted the nginx service als all php pages working again.
    Thank you for sharing your knowledge. It saved my server.

  9. moon
    Permalink

    I literally struggled with this for an entire day. Thank you so much! Wish I could give this post stars or something so that it returns as the first solution for any other frustrated googlers.

  11. Thomas Beutel
    Permalink

    My pleasure, I’m glad it helped. Thank you for the offer of stars, that means a lot to me. If you have a blog you can link to this post or you can tweet this post. That would really help others find this.

  12. Con Chim Nh?
    Permalink

    Hi ! Add that line to fastcgi_params file or a fastcgi.conf file ?

  13. Manuel
    Permalink

    “$request_filename” is enough here, no need to build a path by hand 🙂

  14. marketto
    Permalink

    Thank you, you saved my time)

  15. bryanisimo
    Permalink

    Thanks, you save my life, this happends to me in a nginx update

  16. Jan
    Permalink

    Thanks so much, this sure saved me from a serious headache!

  18. Vasja Zupan
    Permalink

    thanks! saved me too 🙂

  19. Roy Heeneman
    Permalink

    Thank you so much! You made my day!

  20. Will
    Permalink

    Thanks that did the trick after upgrading from nginx 1.4 to 1.9.12

  21. Pavel
    Permalink

    Thank you!
    Why this didnt set by default?

  24. Judas Borbón
    Permalink

    Thanks, Thomas. I was already aware that one needs to specify the request information in the site config before passing it to php-fpm, but this confused the hell out of me because I had a WordPress site in DigitalOcean which doesn’t have this parameter and works fine, but I needed to move the site to a different droplet with a newest version of Ubuntu Server, and there it stopped working. Computers, am I right? ¯_(?)_/¯

  25. Peter Volkov
    Permalink

    That’s crazy! Although I’ve manged to understand this issue myself I’m googling now to find if anybody has an explanation for this behaviour? Why if I set SCRIPT_FILENAME and make a request to nonexitent file I’ll get status 404 and body “File not found.” that was generated by php-fpm. Why there is such big difference if I as /notexisting.php and $document_root/notexisting.php? I think this is bug in php-fpm…

    BTW: SECURITY WARNING FOR EVERYONE HERE:

    We would never had this headache if we had nginx config with:

    try_files $fastcgi_script_name =404;

    This is good performance wise and security requires this:
    http://kaiwangchen.github.io/2012/10/02/understand-the-cgi-fix_pathinfo-security-issue.html

  26. Peter Volkov
    Permalink

    Opened bug report: https://bugs.php.net/bug.php?id=75120

Comments are closed.

x