Diagnose blank PHP pages behind Nginx

A blank browser page is a symptom, not a diagnosis. A hidden PHP fatal error is one possibility; an empty successful response, wrong script path, application logic, or frontend rendering failure can look similar. Start by checking the status and response body, then correlate the request with Nginx and PHP-FPM logs.

curl -i https://example.com/problem-page
sudo tail -50 /var/log/nginx/error.log

Make PHP errors observable

For production, configure the PHP-FPM runtime to log errors rather than display them publicly:

display_errors = Off
log_errors = On
error_reporting = E_ALL
error_log = /var/log/php/app-error.log

Create the intended log directory and grant the FPM worker the required write access. The path is an example. FPM's own master/pool logs and PHP's application error log may be different destinations.

Inspect the configuration used by the FPM service, not just the CLI. php --ini or php -r 'echo php_ini_loaded_file();' reports the CLI configuration. A temporary, access-restricted diagnostic executed through FPM can report its loaded file; remove it after use and avoid publishing a phpinfo() page.

Apply changes through the actual FPM service, for example sudo systemctl reload php8.2-fpm if that installed unit supports reload, otherwise its documented restart procedure.

Enable visible errors only in development

In a private development environment, set display_errors = On in the FPM configuration. For errors that occur after a script starts, temporary code can help:

<?php
ini_set('display_errors', '1');
error_reporting(E_ALL);

This cannot reveal a parse error that prevents that same file from executing, and runtime settings can be constrained by administrative configuration. Read the logs when the page remains blank. Restore production settings before exposing the endpoint.

Work through likely causes

• Script path: Compare root and the FastCGI SCRIPT_FILENAME with the file visible to FPM. A conventional mapping is $document_root$fastcgi_script_name; aliases, chroots, and separate container mounts require additional care. A missing script often produces a “Primary script unknown” or “File not found” response, not necessarily a silent blank page.
• FPM availability: A stopped pool commonly produces 502. Inspect the actual service and listener instead of interpreting an empty browser page as proof of a PHP error.
• Memory exhaustion: Find the operation and allocation pattern before raising memory_limit. A larger limit can merely postpone a leak or oversized workload.
• Missing extensions: Verify the extension in the FPM runtime. An extension loaded by CLI PHP does not establish that the web process loaded it.
• Permissions: FPM must read scripts and dependencies and write only to the application's intended writable directories.

For a conventional root-based PHP location, verify that it sends the expected parameter:

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

Inspect included FastCGI files to avoid conflicting definitions.

FAQ

What if all the logs are empty?

Check the active runtime configuration, log_errors, destination permissions, pool-level overrides, and whether the request reached PHP at all. Some applications route errors through a framework logger. Do not assume every failure must already have produced a PHP log entry.

Why are only some pages blank?

Compare their controllers, templates, queries, and response bodies. The pattern narrows the investigation but does not prove that framework initialization succeeded for every request.

What should I verify after restoring the page?

Keep display_errors off in production and trigger a controlled test error to verify logging. DataKit file-log collection can collect the chosen destination across instances; confirm timestamps and application/host identity so later failures remain traceable.

Reference: PHP error-handling configuration.