• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Resolved Error: 505 Gateway Time-out nginx

Dukemaster

Regular Pleskian
Hi at all,
since I rebuilt my forums from backup over my new server environment (apache with nginx as proxy/PHP 7.0.14 FPM over apache with and serving all static files over nginx.
I get the 505 Gateway Time-out nginx stop error every time when I update the attachements of the board exactly by 25%.
Fehlermeldung 504 Gateway Time-out nginx.jpg
I asked my server administration helper how to fix it.
She told me to write the following code in the additional apache and nginx instructions of domain - webhosting configuration box of the domain in the bottom of this Plesk site.
Code:
fastcgi_read_timeout 300;
I also added another instruction, like written in teh description: This is my code:
gzip_proxied any;
fastcgi_read_timeout 300;
I'm a kind of complete solution worker, so I made this configuration to all of the other 8 domains.
After resolving I make a # reboot,made tested nginx server, restarted nginx server and made a reboot
nginx -t
everything OK
/etc/init.d/nginx restart
But nothing changed in the running update script ! ! ! Stopping like always at 25%.
Perfekte PHP Einstellungen-2.jpg
Additional questions: Do you know which file and path to file this configuration file is?

After the first failed test, I myself made the big mistake:
I wrote the same code in the PHP 7.0.14 configuration box (nginx) of domain webhosting settings. The domain PHP configuration file.
NO error, but after another unsuccessful test in this case I deleted the code from PHP 7.0.14 settings and rebooted.

Perfekte PHP Einstellungen-1.jpg
But in the normal apache and nginx configuration files of each domain I still have this two settings.
Can I test the functionality on over a Bash command or on a website, if it works or not?
How can I fix my main 505 Gateway Time-out nginx error problem?
Perfekte Apache Einstellungen.jpg
Please, sorry so much for a lot of questions. I don't want to destroy the good running system I ever had by this mistake testing in the wrong PHP settings box. And a little help to fix my main problem would be great.
Greets
 

Attachments

  • Perfekte PHP Einstellungen-0.jpg
    Perfekte PHP Einstellungen-0.jpg
    328.2 KB · Views: 19
Last edited:
Hi Dukemaster,

pls. don't mix PHP - settings, with NGINX settings.

Pls. be aware, that (sub)domain - specific PHP - settings depend on the enherited settings in your other php.ini 's. If you don't setup unique (sub)domain - settings, the subscription php.ini is being used.

75148.png
Pls. inspect errors/issues/problems FIRST in your log - files, so that you have a better understanding, what might be mis- or unconfigured. In your case, you will notice errors like: "upstream timed out (110: Connection timed out) while reading response header from upstream", which will then lead you to a KB - article from the Plesk Knowledge - Base:

 
Try to increase the max_execution_time setting of PHP, e.g match it to the the 300 seconds you allow for your Apache to respond to Nginx. Currently your script expires after 30 seconds, so it does not help to let Nginx wait for a max of 300 seconds. Apache simply does not deliver anything after the 30 seconds window has expired. A function like "Dateianhänge aktualisieren" sounds like an awful long, time-consuming process. Maybe even 600 seconds are not enough for that.

Follow UFHH01 hint and the KB article, but also increase the max_execution_time for your PHP script. Maybe try 600 seconds first in PHP settings AND Nginx configuration directives? Then go to 1200, 1800, 2400 ... if the 600 is insufficient. Restart Apache and Nginx after each configuration change for the settings to take effect.
 
Hi Peter Debik,

A function like "Dateianhänge aktualisieren" sounds like an awful long, time-consuming process. Maybe even 600 seconds are not enough for that.
It's not, with wbb, the whole process is devided into small pieces. :)


Hi Dukemaster,

I forgot to mention, that you might consider to add additional NGINX rewrites, as suggested at the woltlab - forums:

For wbb3:
Code:
    # wbb3-rewrites.conf =
    
        if (!-e $request_filename) {
            rewrite ^/tag/([0-9]+)\-([^/\.]*)/?$ /forum/index.php?page=TaggedObjects&tagID=$1 last;
            rewrite ^/user/([0-9]+)/([^/\.]*)/?$ /forum/index.php?page=User&userID=$1&username=$2 last;
            rewrite ^/([^/\.]+)/([0-9]+)\-([^/\.]*)/last\-post\.html$ /forum/index.php?page=Thread&threadID=$2&action=lastPost last;
            rewrite ^/([^/\.]+)/([0-9]+)\-([^/\.]*)/first\-new\-post\.html$ /forum/index.php?page=Thread&threadID=$2&action=firstNew last;
            rewrite ^/([^/\.]+)/p([0-9]+)\-([^/\.]*)/?$ /forum/index.php?page=Thread&postID=$2 last;
            rewrite ^/([^/\.]+)/([0-9]+)\-([^/\.]*)/index([0-9]+)\.html$ /forum/index.php?page=Thread&threadID=$2&pageNo=$4 last;
            rewrite ^/([^/\.]+)/([0-9]+)\-([^/\.]*)/?$ /forum/index.php?page=Thread&threadID=$2 last;
            rewrite ^/([^/\.]+/)*([^/\.]+)/index([0-9]+)\.html$ /forum/index.php?page=Board&boardTitle=$2&pageNo=$3 last;
            rewrite ^/([^/\.]+/)*([^/\.]+)/?$ /forum/index.php?page=Board&boardTitle=$2 last;
            rewrite ^/index\.html$ /forum/index.php?page=Index last;
        }

For wbb4:
Code:
    # wbb4-rewrites.conf =
    
        if (!-e $request_filename) {
            rewrite ^/user/([0-9]+)\-([^/\.]*)/?$ /index.php/User/$1-$2/ permanent;
            rewrite ^/(board[0-9]+\-[^/\.]+/)*board([0-9]+)\-([^/\.]+)/([0-9]+)\-([^/\.]*)/last\-post\.html$ /index.php/Thread/$4-$5/?action=lastPost permanent;
            rewrite ^/(board[0-9]+\-[^/\.]+/)*board([0-9]+)\-([^/\.]+)/([0-9]+)\-([^/\.]*)/first\-new\-post\.html$ /index.php/Thread/$1-$2/?action=firstNew permanent;
            rewrite ^/(board[0-9]+\-[^/\.]+/)*board([0-9]+)\-([^/\.]+)/p([0-9]+)\-([^/\.]*)/?$ /index.php/Thread/$5/?postID=$4&$args#post$4? permanent;
            rewrite ^/(board[0-9]+\-[^/\.]+/)*board([0-9]+)\-([^/\.]+)/([0-9]+)\-([^/\.]*)/index([0-9]+)\.html$ /index.php/Thread/$4-$5/?pageNo=$6 permanent;
            rewrite ^/(board[0-9]+\-[^/\.]+/)*board([0-9]+)\-([^/\.]+)/([0-9]+)\-([^/\.]*)/?$ /index.php/Thread/$4-$5/ permanent;
            rewrite ^/(board[0-9]+\-[^/\.]+/)*board([0-9]+)\-([^/\.]+)/index([0-9]+)\.html$ /index.php/Board/$2-$3/?pageNo=$4 permanent;
            rewrite ^/(board[0-9]+\-[^/\.]+/)*board([0-9]+)\-([^/\.]+)/?$ /index.php/Board/$2/ permanent;
            rewrite ^/user/blog([0-9]+)\-([^/\.]*)/entry([0-9]+)\-([^/\.]*)/?$ /blog/index.php/Entry/$3-$4/ permanent;
            rewrite ^/user/blog([0-9]+)\-([^/\.]*)/category([0-9]+)\-([^/\.]*)/?$ /blog/index.php/EntryList/?userID=$1 permanent;
            rewrite ^/blog/category([0-9]+)\-([^/\.]*)/?$ /blog/index.php/Blog/ permanent;
            rewrite ^/user/blog([0-9]+)\-([^/\.]*)/?$ /blog/index.php/EntryList/?userID=$1 permanent;
            rewrite ^/user/gallery([0-9]+)\-([^/\.]*)/photo([0-9]+)\-([^/\.]*)/?$ /gallery/index.php/Image/$3-$4/ permanent;
            rewrite ^/user/gallery([0-9]+)\-([^/\.]*)/album([0-9]+)\-([^/\.]*)/?$ /gallery/index.php/Album/$3-$4/ permanent;
            rewrite ^/gallery/category([0-9]+)\-([^/\.]*)/?$ /gallery/index.php/Gallery/ permanent;
            rewrite ^/user/gallery([0-9]+)\-([^/\.]*)/?$ /gallery/index.php/Image/$3-$4/ permanent;
        }
 
Wonderful Gentlemen, I started my first woltlabburningboard exactly 10 years ago. Team member and developer of addons helped me running my own server. The software constantly grows, exactly the same like Plesk does.
Tomorrow the final board 5.0 with amazing Suite 3.0 (former WFC) and functionalities creating own sites without any purchasing software... I love it..From 2009 to 2012 realized a Cam and Voice Flash Chat connected with WBB over streaming server RED5 on Debian with Plesk. but they stopped the project Flashchat by Darrens 5$ Script Archive, so I had to stop it too because of security risks. But It worked...

THANKS YOU again for your great help, @UFHH01. I did what you suggested and now maintance runs like faster like never before. Perhaps, like you have seen, for the heavy images files until 20mb and adobe .psd(s) of the galleries the co-admin made heavy changes in PHP 7.0.14 settings (also in my.cnf) like 196M memory_limit, 46 post_max_size, 40 upload_max_filesize... and now your 300 execution_time instead of 30.
I use much heavy image loads and imagick since years and over 20 Chatrooms, blogs, streaming website background music...

Could you please only tell me, where the nginx configuration file is (path) and what's the exact name is?
The box with input "fastcgi_read_timeout 300;" in bottom of additional settings for nginx is related to it and makes the changes in this conf-file.

Now it's like a dream coming real. Best performance... Good morning to all of you. :)
 
Last edited:
I forgot to mention, that you might consider to add additional NGINX rewrites, as suggested at the woltlab - forums:
I had these rules for the last two or more years in my .htaccess, but it is only necessary for a few months in order that searchmaschines like Google save the path.
Then you can delete them. (Apache - SEO Linkumschreibungen)

Woltlab Support - Blog Comments <-- Permalink
Dukemaster05 - 22. November 2016 [/B][/SIZE]
Umleitung wieder entfernen!
Hatte diese Umleitung jahrelang auch erfolgreich genutzt, über 4.0 bis 4.1. Nun aber habe ich kürzlich die htaccess mal aufräumen wollen und entfernte diese Umschreibungen, ließ nur die die rewrite auf https:www drin. Einfach nur zum Test!
Ergebnis: Keinerlei Ausfälle und Fehlanzeigen.
Wüsste gerne wie das kommt und ob es spruchreif ist, bzw es an anderen zwischenzeitlichen Änderungen oder Updates liegt? Gruss

- 22. November 2016
Durch den Umleitungscode 301 aktualisieren die Suchmaschinen die Links entsprechend. Nachdem die erneute Indexierung durchgelaufen ist, wird die Umschreibung prinzipiell nur noch für interne Links in Beiträgen benötigt. Diese werden aber von vielen Administratoren direkt in der der Datenbank korrigiert. Daher ist die Umschreibung nach spätestens einigen Monaten unnötig.[/B][/SIZE]
 
Last edited:
Hi Dukemaster,

Could you please only tell me, where the nginx configuration file is (path) and what's the exact name is?
Again, I would like to point you to another KB - article ( I hate that to write, but I already suggested to bookmark it, pls. ):


I had these rules for the last two or more years in my .htaccess, but it is only necessary for a few months in order that searchmaschines like Google save the path.
Then you can delete them. (Apache - SEO Linkumschreibungen)
Dear Andrea Berg, ( :D:p:D )
no, it is NOT unnecessary to leave these ( SEO ) rewrites where they are ( ".htaccess" + "Additional NGINX directives" ), but rather essential to tell apache+nginx, where they should look for files and folders, depending to the settings for the corresponding wbb - installation, how to handle permalinks, when there is a combination of apache2+nginx+php-fpm in use for a domain. Unfortunately, Woltlab still doesn't present a decent NGINX support, which could avoid ( possible ) issues/errors/problems, when webserver - combinations are used. I have to point out though, that "wbb" is still one of the fastest and best forum - software, but there is still much room for improvements. ;)

@Dukemaster: Just tell her to avoid postings, which are beyond her knowledge and she definelty hasn't got much knowledge about NGINX and SEO. :p:p:p
 
Hi, @UFHH01,

To the problem itself - I made a big mistake! ! !
I meant ONLY these one of the older woltlab versions.
The rules of your actual running WBB version have to be included ! Asolutely !
My actual version since around one year is 4.1 (updated from 4.0).
So, for the first period after the update it's necessary to also include the rewrites of the former version 4.0.
After a few months you can delete the older 4.0 rules but:
YOU HAVE TO USE THE ACTUAL REWRITES (in my case 4.1) OF YOUR CURRENT VERSION - Only the rules of the former version could be deleted after a few months!

Greets
 
Last edited:
Hi friends, this topic is a never ending story, isn't it.
Monday after one year it was upgrade time at Woltlabs. I wondered to get the same problem with timeout again.
So, the support article should lead me to heaven, but nothing at all. Wondered to find the link unaccessible like so many others.
I looked and searched for half an hour to find a similar one, but there is no. Would be nice if Plesk Support which is great and helps me often could make a new one related to this problem.

Greets and happy new year at all... :)
 
Thank you very much @IgorG. Increasing to 300 was not enough in this case. The actualization of one animated.gif (3 Minutes long mini-video called "Beating Tetris") takes always around 8 minutes. Increasing to recommended values of 1200 sec. solves the problem.
:)
 
Back
Top