[JAY]

How do you fix a 502 after changing PHP version in aaPanel?
Check the site's Nginx error log, confirm its selected PHP version, and verify that the matching PHP-FPM service is healthy and listening where Nginx expects it. Restore the last working selection if necessary and application-compatible. A 502 alone does not identify the cause.

Scope and review: Documentation reviewed 9 October 2026. This covers Nginx with panel-managed PHP-FPM after a PHP-version change, not every 502 or an OpenLiteSpeed/Apache deployment. Fresh-VPS reproduction and screenshots are pending. Record aaPanel, OS, Nginx and PHP versions. PHP 8.3 and example.com below are placeholders.

1. Correlate the failure with the site's error log
Confirm the actual log path in aaPanel and reproduce one failing request:

Code:Copy

sudo tail -n 50 /www/wwwlogs/example.com.error.log

If the log reports:

Code:Copy

connect() to unix:/tmp/php-cgi-83.sock failed (2: No such file or directory)

Nginx cannot find that configured Unix endpoint. The selected service may be stopped, may have failed to start, or may listen somewhere else. Confirm both sides before changing configuration.

Different messages need different checks:

• Permission denied: inspect socket ownership/mode and security-policy denials; do not use chmod 777 or disable security globally.
  
• Connection refused: check whether the configured listener is active.
  
• Upstream timed out: investigate slow application/database work and resource pressure; do not blindly increase timeouts.
  

2. Check the selected PHP service
Prefer the panel's PHP service controls. If this installation uses the documented init script, an example status check is:

Code:Copy

sudo /etc/init.d/php-fpm-83 status ls -l /tmp/php-cgi-83.sock

A socket file alone is not proof of a healthy service. Compare the site's upstream with PHP-FPM's configured listen endpoint. Do not create the socket yourself or change the application's PHP version without compatibility checks.

3. Inspect startup/configuration errors
A configuration check for this example installation:

Code:Copy

sudo /www/server/php/83/sbin/php-fpm -t

If validation fails, read the reported file and setting. Possible causes include invalid configuration or an incompatible/missing extension. Install only extensions required by the application for the selected PHP version; do not disable arbitrary extensions or security controls as a shortcut. After correcting the cause, start the affected service through the panel. If using the matching init script:

Code:Copy

sudo /etc/init.d/php-fpm-83 start

Changes to a shared PHP service can affect other sites using it.

4. Validate Nginx only if its configuration changed
Use the panel-managed binary on this example installation:

Code:Copy

sudo /www/server/nginx/sbin/nginx -t

Do not reload if validation fails. If validation passes and the configuration was deliberately changed, use the supported panel reload control. Restoring PHP-FPM alone may resolve the failure without changing Nginx.

5. Verify recovery and keep a rollback path

• The selected PHP service stays running and the expected listener is active.
  
• A real PHP/application route loads, not just a static HTML page.
  
• A new request produces no matching upstream error.
  
• Other sites using that PHP version still work.
  
• Required extensions and application/database operations are checked.
  

If a live site remains down after a version switch, consider restoring its previous working PHP selection through the panel while diagnosing, provided the application still supports it. Back up settings before further changes.

For help: Share the version details, selected PHP version, time of failure and a few redacted error lines. Do not share credentials, tokens or a full configuration dump.

Official references: aaPanel PHP selection and logs; Nginx FastCGI upstreams; PHP-FPM configuration.

Related: aaPanel file and log locations · Setup checklist.