Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

General Questions

General questions about getting started with SilverStripe that don't fit in any of the categories above.

Moderators: martimiz, Sean, biapar, Willr, Ingo, swaiba, simon_w

502 Bad Gateway in Admin


6 Posts   861 Views


11 July 2013 at 3:29am Community Member, 5 Posts

I recently deployed a SilverStripe (3.0.5) website which was running fine, however because of (non-SS related) server problems the site was moved to a new servers running Plesk 11. The backend will now throw a 'Bad Gateway' error when trying to load the site tree (list and tree views).

I have been told the only way I can get around this is by increasing the header_buffer_size in nginx. This is not an option as the host will not give me access to this setting and are unwilling to budge.

I have commented out the 'combine_files' Requirements in CMSMain.php and the backend now loads, obviously without the JS functionality it needs. Is there a way to flush the buffer between each requirement?

Any help on this would be amazing, I've had the problem for a few weeks now and got nowhere.

Thanks All!


12 July 2013 at 7:34pm Community Member, 787 Posts

I'd advise you not to run Silverstripe on Plesk in combination with nginx. In my experience, that is quite a fickle setup. The default Plesk Apache environment works, but I found customizing nginx to be a pain.


12 July 2013 at 8:46pm Community Member, 5 Posts

Thanks for the advise fuzz10. Unfortunately the hosting of the site is out of my control. I deployed to my customers host a few months back. It was running Plesk 10, however the host had overloaded the server with too many sites forcing it to timeout for several hours a day. The host company then 'at no cost to the customer' moved the site to a newer server. They are now holding me responsible, insisting that if they upgrade their servers, their customers need to update their websites, not the other way round.

It's that classic three way battle, my customer doesn't know what to think, except that I've built a website that 'doesn't work'. I have tried explaining that it was working when I set it up, and as I didn't move it it really is nothing to do with me. Their host has changed the platform it is running on IMO, so they should sort it out. However they are not willing to make any changes to either the website or the hosting environment.

Any advice on this situation would be greatly appreciated. Many thanks!


12 July 2013 at 8:51pm Community Member, 787 Posts

hmmpf , that sucks. I know the situation though.

Well, they can easily change the plesk environment to apache only. If they refuse, I would not bother and put the site on a host that is familiar to you. Then leave it up to your client to fight the battle to get the DNS changed or get their own hosting provider to change settings. You run the risk of wasting a crapload of hours fiddling with nGINx and Plesk , it's not worth it.


12 July 2013 at 8:58pm Community Member, 5 Posts

I've set the website up on my host using the latest DB and assets so its an exact copy. I've told them they can park there until they sort something out but will need to get their host to sort DNS out. As yet they've not took me up on the offer.

The whole situation really does suck. I feel their host has used me as a scape goat.

Can they change the environment to Apache only without affecting any of the other vhosts on the server, or is it a change to the whole server? I really do hate Plesk, with a vengeance!

Jay B

23 May 2014 at 12:28pm Community Member, 1 Post

I had the same error messages about 503 Bad Gateway, both in nginx and Apache, and after looking through the log files ran across an error in the nginx log files that shed some light.

PHP message: PHP Warning: Requirements_Backend::process_combined_files(): Couldn't create '/var/www/assets/_combinedfiles//lib.js' in /var/www/framework/view/Requirements.php on line 1083"

After setting permissions so that PHP (whether PHP-FPM through nginx or Apache user) could write to "/var/www/assets/*" the errors went away because the framework now has permission to write the .js files.

Hope this helps others that might run across the same issue.