Fixing WordPress Frontend 502 Error in LNMP 1.2 Due to .user.ini

Recently, I migrated from AMH 4.2 to Junge's LNMP 1.2 one-click package. While the data transfer was successful, a problem arose: the WordPress frontend displayed a 502 Bad Gateway error. Following official suggestions to adjust php.ini and php-fpm configurations did not resolve the issue; the frontend remained sluggish or completely inaccessible, sometimes showing a blank screen. I wondered if others had encountered similar situations.

Interestingly, the WordPress backend logged in normally without lag. Suspecting a plugin issue, I disabled all plugins, but the frontend still failed to load. I then considered a theme problem and switched to the default official theme, yet the issue persisted; the homepage remained inaccessible and timed out.

This was quite frustrating. I checked the website logs, Nginx logs, and PHP-FPM logs, but found no errors. This suggested that plugins and themes were not the cause. Finally, I discovered that a .user.ini file was the culprit. After creating a site with LNMP 1.2, a hidden .user.ini configuration file is generated in the site root directory, which cannot be directly modified or deleted.

LNMP 1.1 and earlier versions used open_basedir settings in php.ini. However, LNMP 1.2 and higher versions use .user.ini for cross-directory protection. This file resides in the website root directory and allows you to modify the open_basedir value to restrict directory access.

Solution:

1. Execute the following command to remove the immutable attribute from the .user.ini file:

   chattr -i /path/to/your/site/.user.ini
   

2. Delete the contents of the .user.ini file completely, save the changes, and then re-apply the immutable attribute:

   chattr +i /path/to/your/site/.user.ini
   

3. Restart the LNMP related services:

   lnmp restart
   

The problem was finally resolved, and the frontend loaded normally again. If you encounter this issue, you can refer to this solution. I searched online for a long time without finding a fix and spent several hours troubleshooting before discovering the solution.