Valet: 504 Gateway Timeout

[pryley]

I think laravel/valet should provide more relaxed defaults for a development environment. Importing a large(ish) database in phpmyadmin causes a 504 Gateway Time-out error.

To fix the 504 error you need to change the default timeout to more than 30 seconds. Here's how to change it to 5min (300 seconds):

1. /usr/local/etc/php/{version}/conf.d/php.ini

max_execution_time = 300

1. https://github.com/laravel/valet/blob/master/cli/Valet/PhpFpm.php#L57

function updateConfiguration()
{
    $contents = $this->files->get($this->fpmConfigPath());

    $contents = preg_replace('/^user = .+$/m', 'user = '.user(), $contents);
    $contents = preg_replace('/^group = .+$/m', 'group = staff', $contents);
    $contents = preg_replace('/^listen = .+$/m', 'listen = '.VALET_HOME_PATH.'/valet.sock', $contents);
    $contents = preg_replace('/^;?listen\.owner = .+$/m', 'listen.owner = '.user(), $contents);
    $contents = preg_replace('/^;?listen\.group = .+$/m', 'listen.group = staff', $contents);
    $contents = preg_replace('/^;?listen\.mode = .+$/m', 'listen.mode = 0777', $contents);
    // Enable the "request_terminate_timeout" parameter
    $contents = preg_replace('/^;?request_terminate_timeout = .+$/m', 'request_terminate_timeout = 300', $contents);

    $this->files->put($this->fpmConfigPath(), $contents);
}

1. https://github.com/laravel/valet/blob/master/cli/stubs/valet.conf#L25

location ~ \.php$ {
    fastcgi_split_path_info ^(.+\.php)(/.+)$;
    fastcgi_pass unix:VALET_HOME_PATH/valet.sock;
    fastcgi_index VALET_SERVER_PATH;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME VALET_SERVER_PATH;
    # Set the "fastcgi_read_timeout" parameter
    fastcgi_read_timeout 300;
}

1. https://github.com/laravel/valet/blob/master/cli/stubs/secure.valet.conf#L34

location ~ \.php$ {
    fastcgi_split_path_info ^(.+\.php)(/.+)$;
    fastcgi_pass unix:VALET_HOME_PATH/valet.sock;
    fastcgi_index VALET_SERVER_PATH;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME VALET_SERVER_PATH;
    # Set the "fastcgi_read_timeout" parameter
    fastcgi_read_timeout 300;
}

[3alampro]

thanks this helped me with Ajax file uploading
I no longer see 504 Gateway Timeout when uploading files with Ajax request

[mityukov]

1. Which files should be changed on an existing/working Valet installation? Something in ~/.valet ?

2. Is it possible to disable Timeout completely (I use Valet on my notebook, not on server, so I an stop any processes myself, if need to)?

[lazyguru]

Valet just installs nginx via brew (unless it is already installed). You can always modify the configs under /usr/local/etc/nginx/. If you have used valet secure on the site then there is also a site specific nginx config created under ~/.valet/Nginx/

[tiagomatosweb]

I've got the same issue, but much more frequent when I make multiple requests.
However,

1. /usr/local/etc/php/{version}/conf.d/php.ini
   I don't have php.ini. I do have php-memory-limits.ini instead. Should I create php.ini or set in the php-memory-limits.ini?

2/3/4 - Couldn't find those files, any clue?

$ valet -V
Laravel Valet version 2.0.5

$ php -v
PHP 7.1.8 (cli) (built: Aug  7 2017 15:02:45) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2017 Zend Technologies

$ ls /usr/local/etc/php/7.1/conf.d/
php-memory-limits.ini 

[bkkrishna]

Any replies/solutions to @tiagomatosweb's problem? I am stuck with the same problem.

[sylouuu]

For those who are stuck with 5 concurrent max requests:

/usr/local/etc/php/7.1/php-fpm.d/www.conf

pm.max_children = 200

If you want to boost the perf:

pm.start_servers = 20
pm.min_spare_servers = 10
pm.max_spare_servers = 20
pm.process_idle_timeout = 10s
pm.max_requests = 500

sudo brew services restart php71

[hanjinye]

非常感谢楼主,对于一直没有解决问题的小伙伴看好了. 直接修改 /usr/local/etc/nginx/valet/valet.conf 在差不多22行左右

   location ~ \.php$ {
        #下面这行是新加的,加好就好了 哈哈 
        fastcgi_read_timeout 300; 
        fastcgi_split_path_info ^(.+\.php)(/.+)$;

当然php.ini里也是要设置好的
php71的配置在 /usr/local/etc/php/{version}/php.ini
不要偷懒,输入phpinfo就能看到配置文件地址.
改好后记得要重启valet

[tiagomatosweb]

@bkkrishna I have solved my issue adding

client_header_timeout 3000;
client_body_timeout 3000;
fastcgi_read_timeout 3000;
fastcgi_buffers 8 128k;
fastcgi_buffer_size 128k;

to ~/usr/local/etc/nginx.confg file under http {}object.

Then restart the services valet restart

[ctf0]

maybe instead of fiddling around to find the correct files to change, @adamwathan could valet instead make an alias to the files inside the .valet folder ?

[mattstauffer]

Closing this issue as it seems there are myriad solutions presented but no forward movement for their impact on Valet; @ctf0 if you'd like to continue that proposal, would you please open it as a separate (and more fleshed-out) issue?

[clarknelson]

This is still an issue! My valet installation is giving me a 504 and I do not know how to fix it

[clarknelson]

Notice these two lines:

2018/12/12 10:21:47 [crit] 36021#0: *74 connect() to unix:/Users/clarknelson/.config/valet/valet.sock failed (2: No such file or directory) while connecting to upstream, client: 127.0.0.1, server: lc.test.test, request: "GET /favicon.ico HTTP/2.0", upstream: "fastcgi://unix:/Users/clarknelson/.config/valet/valet.sock:", host: "focus.test", referrer: "https://focus.test/"

2018/12/12 10:21:49 [crit] 36020#0: *77 connect() to unix:/Users/clarknelson/.config/valet/valet.sock failed (2: No such file or directory) while connecting to upstream, client: 127.0.0.1, server: , request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/Users/clarknelson/.config/valet/valet.sock:", host: "vwa.test"

The /Users/clarknelson/.config/valet/valet.sock file exists, but nothing prints when I use cat on it. When I try to open it with a text editor it says Unknown system error -102.

I've noticed that the difference between these two lines is that the second does not have a server property, and the first is an incorrect server property. The first website (focus.test) will work while the second (vwa.test) returns a 504 error.

Am I on the right track here?

[drbyte]

The /Users/clarknelson/.config/valet/valet.sock file exists, but nothing prints when I use cat on it. When I try to open it with a text editor it says Unknown system error -102.

That's normal. Socket files aren't intended to be read/used by other than the system service that created them. You can't cat its contents, nor can you view it in a text editor.

[clarknelson]

Okay thank you, I figured as much, more concerned about the second issue. Do you know how these log lines are generated? I have removed ~/.config/valet/ and run valet install but I still am having an issue with this one specific website. Are there any website specific configs I should look for? Strange that other sites work fine.

[clarknelson]

It looks like website.test/admin works while website.test seems to not respond and then eventually rest on a 504 error.

[drbyte]

That sounds like an nginx misconfiguration. The gateway timeout is most likely referring to nginx waiting for php-fpm to respond. If the website.test without trailing slash is timing out, then perhaps the nginx config doesn't know how to handle defaults, or you've got a custom nginx rule that's not handling the base domain-without-params properly.

If you hadn't said that website.test/admin works properly, then I'd likely be suggesting that you've upgraded PHP versions and your old nginx configs are pointing to an old missing PHP or a valet.sock that isn't being served by a real actual functioning service (ie is an artifact from an old version that didn't shut down and clean itself up properly).

You might check whether your /usr/local/etc/nginx configs are damaged or have been customized beyond the defaults (valet assumes defaults, and applies only a few small customizations to point to valet directories).
In a more drastic situation I'd reset nginx to defaults by removing with brew uninstall nginx and delete the /usr/local/etc/nginx directory and re-run valet install.

It's also possible that you've got some file in your website.test public folder that's doing a silent redirect to some other resource that truly is not responding with other than the 504 error. In this case it has nothing to do with valet at all, but rather your app.

[clarknelson]

Thank you for your help.

It looks like maybe I spoke too soon, both the normal and /admin versions of the site return 504.

I get a few messages like this when running valet install implying that php 7.3 needs to be installed. I don't believe this is the culprit because other sites work. Also 7.3 isn't even available on homebrew yet.

PHP Warning: file_get_contents(/usr/local/etc/php/7.3/php-fpm.d/www.conf): failed to open stream: No such file or directory in /Users/clarknelson/.composer/vendor/laravel/valet/cli/Valet/Filesystem.php on line 112

I've already uninstalled nginx, removed the nginx directory, and then reinstalled both nginx and valet. I am getting the same error.

All of the websites work besides this one, which makes me think it is a problem with the project. Unfortunately I don't have any clue what this is. There is no .htaccess for nginx, I have tried to clean up any config files. Wow I am frustrated

[clarknelson]

Now all the websites are giving me 504. What a mess! Nothing is working anymore

[drbyte]

PHP 7.3 is available on homebrew.

If everything is saying bad gateway then it's likely that your PHP is the problem.

A complete reset of valet (er, well, the nginx/php part anyway; I'm assuming dnsmasq is resolving the .test TLD properly) can be done via:

valet stop
brew services list  # (should show both nginx and php as stopped)
brew uninstall php nginx
brew update
rm -rf /usr/local/etc/nginx /usr/local/etc/php
rm -rf ~/.config/valet
composer global update
valet install
valet start

[clarknelson]

Seems to be working a bit better. I received the following error during install though:

Installing php71...
[php71] is not installed, installing it now via Brew... 🍻
Updating PHP configuration...

In Brew.php line 195:
Unable to determine linked PHP.

[drbyte]

What's the output of brew info php and brew services list ?

[clarknelson]

brew services list

dnsmasq started root /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist
mysql started root /Library/LaunchDaemons/homebrew.mxcl.mysql.plist
nginx started clarknelson /Users/clarknelson/Library/LaunchAgents/homebrew.mxcl.nginx.plist
php started root /Library/LaunchDaemons/homebrew.mxcl.php.plist
[email protected] started clarknelson /Users/clarknelson/Library/LaunchAgents/homebrew.mxcl.[email protected]

[clarknelson]

brew info php

php: stable 7.3.0 (bottled)
General-purpose scripting language
https://secure.php.net/
/usr/local/Cellar/php/7.3.0 (521 files, 76.5MB) *
Poured from bottle on 2018-12-12 at 12:10:06
From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/php.rb
==> Dependencies
Build: httpd ✘, pkg-config ✘
Required: apr ✔, apr-util ✔, argon2 ✔, aspell ✔, autoconf ✔, curl-openssl ✔, freetds ✔, freetype ✔, gettext ✔, glib ✔, gmp ✔, icu4c ✔, jpeg ✔, libpng ✔, libpq ✔, libsodium ✔, libzip ✔, openldap ✔, openssl ✔, pcre ✔, sqlite ✔, tidy-html5 ✔, unixodbc ✔, webp ✔
==> Caveats
To enable PHP in Apache add the following to httpd.conf and restart Apache:
LoadModule php7_module /usr/local/opt/php/lib/httpd/modules/libphp7.so

<FilesMatch \.php$>
    SetHandler application/x-httpd-php
</FilesMatch>

Finally, check DirectoryIndex includes index.php
DirectoryIndex index.php index.html

The php.ini and php-fpm.ini file can be found in:
/usr/local/etc/php/7.3/

To have launchd start php now and restart at login:
brew services start php
Or, if you don't want/need a background service you can just run:
php-fpm
==> Analytics
install: 48,923 (30 days), 128,090 (90 days), 366,326 (365 days)
install_on_request: 44,452 (30 days), 116,312 (90 days), 330,600 (365 days)
build_error: 0 (30 days)

[drbyte]

I'm not understanding why your valet is assuming it needs php71. Especially when it shows php as running and is linked to 7.3.

Did you run composer global update and let it update valet?
If you run valet it gives you a list of commands, but displays a version number at the top. What's that version number?
(An outdated version of valet (prior to 2.1.5) won't recognize PHP 7.3 as a version number.)

You might want to run brew update to ensure you've got the latest definitions for brew.

It might also be worth running brew doctor to expose any "issues" brew notes with your system.

[clarknelson]

I'm sorry I didn't specify this, I installed 7.3 as php when installing [email protected] did not seem to work.

composer global update has already been run and everything is up to date.

valet tells me it is at version 2.1.5

brew update is "Already up-to-date."

There were a few problems with brew doctor but I have fixed them :)

I think I am almost there, I see a JIT compilation failed: no more memory error on the front-end. Likely I will need to readjust some settings.

[clarknelson]

Well i've disabled the php error using the line pcre.jit=0 in php.ini and I managed to get several websites back up! The original "problem" website is still giving me a 504, but it is likely related to another issue :/ I am running an AJAX call on the homepage which may be throwing a 504, website.text/admin does work now for the problem website.

[drbyte]

I'm glad you've got it reset and working now.

(for the "problem" domain, perhaps renaming it or linking to it on a different domain with valet link may be useful to see if the problem "follows" or if it's specific to the domain name)

Good luck with resolving your app-specific issue!

[clarknelson]

Thanks again for your help, the same 504 error appears on the new domain unfortunately, and not much success on disabling the AJAX call.

[clarknelson]

I was experiencing this issue because I was trying to preform an image transform on an asset that does not exist. (I am using Craft CMS)

[simonhamp]

I'm also seeing this in the Statamic CP when it's attempting to load images via AJAX. My only solution so far is valet restart. As soon as I hit a page in the CP that tries to process a bundle of images, it fails and times out for every request after that.

[clarknelson]

@simonhamp make sure all of the images exist !

[simonhamp]

They do. I think I’ve managed to solve it by increasing the number of workers nginx spins up

[AbhinavDobhal]

Solving this issue is easy: just open the file /usr/local/etc/nginx/valet/valet.conf and add the following lines to the block location ~ .php$ { } :
proxy_connect_timeout 600;
proxy_send_timeout 600;
proxy_read_timeout 600;
send_timeout 600;
fastcgi_read_timeout 300;
fastcgi_buffers 8 128k;
fastcgi_buffer_size 256k;

Now all you have to do is to run on your valet restart terminal and everything should work fine.

[drbyte]

Thanks @AbhinavDobhal

Putting them in /usr/local/etc/nginx/fastcgi_params works well too, since it's a central location and valet loads that file from the same block you mentioned. I recently started exploring using the following to test a suggestion made elsewhere for cookie payload size issues.

/usr/local/etc/nginx/fastcgi_params

...

# Very large cookies/headers may throw errors without the following (extremely generous) settings:
fastcgi_buffer_size 4096k;
fastcgi_buffers 128 4096k;
fastcgi_busy_buffers_size 4096k;

# Long-running/slow services
fastcgi_read_timeout 600;
proxy_connect_timeout 600;
proxy_send_timeout 600;
proxy_read_timeout 600;
send_timeout 600;

[fbenas]

HI all,

I have been experiencing the same issue. I followed the same solution as @simonhamp.

For anyone else still having trouble, I specifically edited /usr/local/etc/php/7.3/php-fpm.d/www.conf

With the following updates:

pm.max_children = 200
pm.start_servers = 20
pm.min_spare_servers = 10
pm.max_spare_servers = 20
pm.process_idle_timeout = 10s
pm.max_requests = 500

[Pab89]

I spent a lot of time trying to find ~/.valet/Nginx, turns out in newer versions of valet it is under ~/.config/Valet/Nginx. :)

[jasperf]

# Very large cookies/headers may throw errors without the following (extremely generous) settings:
fastcgi_buffer_size 4096k;
fastcgi_buffers 128 4096k;
fastcgi_busy_buffers_size 4096k; 
# Long-running/slow services
fastcgi_read_timeout 600;
proxy_connect_timeout 600;
proxy_send_timeout 600;
proxy_read_timeout 600;
send_timeout 600;

Added a new fastcgi_params inside ~/.config/Valet/Nginx with these details and did a valet restart and that worked. Thanks!