Valet: Secure sites connection refused

Created on 31 Jan 2017 · 19Comments · Source: laravel/valet

I'm seeing an issue (Valet 2.0.3) where securing a site throws no errors in terminal or ~/.valet/Log/error.log. Pinging the site works fine, but visiting the site through any browser returns the connection refused page.

Has anyone else experienced and/or fixed this?

NB. There's a few threads on issues with securing sites, but I think my issue is different so opening a clean issue.

Source

jsengstrom

Most helpful comment

Hey there 🙂 ,

just wanted to leave an info that might help resolve the problem for some Valet users.

I just ran into the same problem. Securing the site via valet secure seemed to work with no issues since Valet reports no problems. Accessing the site in the browser however results in an ERR_CONNECTION_REFUSED.

The ~/.valet/Log/nginx-error.log log was empty. Peaking into the /usr/local/var/log/nginx/error.log log like @drbyte suggested helped me finding the solution for my particular problem:

In my case the log file stated [...] [emerg] 65848#0: the "http2" parameter requires ngx_http_v2_module in /Users/[...].

I had nginx already installed at the time i installed Valet so valet install skipped installing nginx. As the log file stated my nginx installation was missing the ngx_http_v2_module for http2 support. However the nginx vhost configurations Valet creates assume this module is available in the listen directive: listen 443 ssl http2;.

Since valet installs nginx with brew install nginx --with-http2 this particular problem certainly won't occur on systems not having nginx already installed.

Reinstalling nginx with the http2 module solved it for me:
sudo brew services stop nginx
brew remove nginx
brew install nginx --with-http2
sudo brew services start nginx

Maybe Valet should also check for http2 support when checking if nginx is installed. One solution might be checking the output of nginx -V (which provides the switches nginx has been configured with) and checking for the existance of the --with-http_v2_module flag.

Hope this info is useful to anyone.
~Regards

ghost on 27 Feb 2017

👍12 ❤4 🎉4

All 19 comments

I'm getting the same. I have to completely remove the ~/.valet folder and reinstall valet to bring it back to life again (valet unsecure has no effect).
I need secure working as I am at a critical stage in a project where I need to add secure payments.

One thing I have noticed is that there is no crt file being generated in ~/.valet/Certificates

davebeesley on 6 Feb 2017

I'm experiencing this too, although in my case .crt files are being generated. Having a tough time tracking down the issue, though. Nothing showing up in logs, which is rather irritating.

tnorthcutt on 9 Feb 2017

Due to the timeframe of my project, I have had to install Homestead to get around this

davebeesley on 10 Feb 2017

If you're not seeing supporting details in ~/.valet/Log/error.log then try also inspecting /usr/local/var/log/nginx/error.log and /usr/local/var/log/php-fpm.log

drbyte on 10 Feb 2017

I've got this working in the end, by completely removing valet and brew services from my machine. I then reinstalled valet, then one by one removed and reinstalled/started nginx, php and dnsmasq.

Strangely after this secure started working, but MariaDB stopped connecting. At this point I'd lost so much time to the terminal that I just deleted it and installed straight upmySql instead and got on with my day job. Gotta remember to get Maria working again at somepoint though!

jsengstrom on 10 Feb 2017

I had the exact same situation at one point. I managed to kill my local mariadb. It was at this point I switched to Homestead

davebeesley on 10 Feb 2017

😄1

Looking at /usr/local/var/log/nginx/error.log, I see the following:

2017/02/14 15:43:33 [emerg] 48386#0: bind() to 0.0.0.0:80 failed (48: Address already in use)
2017/02/14 15:43:33 [emerg] 48386#0: bind() to 0.0.0.0:80 failed (48: Address already in use)
2017/02/14 15:43:33 [emerg] 48386#0: bind() to 0.0.0.0:80 failed (48: Address already in use)
2017/02/14 15:43:33 [emerg] 48386#0: bind() to 0.0.0.0:80 failed (48: Address already in use)
2017/02/14 15:43:33 [emerg] 48386#0: bind() to 0.0.0.0:80 failed (48: Address already in use)
2017/02/14 15:43:33 [emerg] 48386#0: still could not bind()

Despite plenty of googling about, I can't come up with a solution 😕

tnorthcutt on 14 Feb 2017

Hey there 🙂 ,

just wanted to leave an info that might help resolve the problem for some Valet users.

The ~/.valet/Log/nginx-error.log log was empty. Peaking into the /usr/local/var/log/nginx/error.log log like @drbyte suggested helped me finding the solution for my particular problem:

In my case the log file stated [...] [emerg] 65848#0: the "http2" parameter requires ngx_http_v2_module in /Users/[...].

Since valet installs nginx with brew install nginx --with-http2 this particular problem certainly won't occur on systems not having nginx already installed.

Reinstalling nginx with the http2 module solved it for me:
sudo brew services stop nginx
brew remove nginx
brew install nginx --with-http2
sudo brew services start nginx

Hope this info is useful to anyone.
~Regards

ghost on 27 Feb 2017

👍12 ❤4 🎉4

I think I found the issue - Certificates got generated corrupted and a million times
https://github.com/laravel/valet/issues/326#issuecomment-282964486

fabianhenzler on 28 Feb 2017

any news on this? I'd love to get my green chain back :)

fabianhenzler on 8 Mar 2017

I had this problem and solved it by just updating my Valet installation with composer.

composer global update

and then running:

valet install

vinnyamp on 17 Jun 2017

👍5 😄2 ❤1 🎉1

Chrome is still doing the same thing after following the steps @vinnyamp, & @one4sorrow recommended. What information would be helpful. This issue only happens with google chrome as well, firefox works perfectly, which is interesting meaning that it might be something specific to google chrome.

ryangurn on 20 Dec 2017

Are you still using .dev? Chrome fucked that up for everyone so switch to a
different TLD if so.
On Wed, Dec 20, 2017 at 2:17 PM Ryan Gurnick notifications@github.com
wrote:

Chrome is still doing the same thing after following the steps @vinnyamp
https://github.com/vinnyamp, & @one4sorrow
https://github.com/one4sorrow recommended. What information would be
helpful. This issue only happens with google chrome as well, firefox works
perfectly, which is interesting meaning that it might be something specific
to google chrome.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/laravel/valet/issues/307#issuecomment-353155924, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AEH3bGWIqY4c-UgdpNCKEkduninI8Hxpks5tCVxlgaJpZM4LyktT
.

adamwathan on 20 Dec 2017

👍4

Guys try securing your sites with valet secure examplesite from your site directory.This worked for me with Valet Linux.Hope this helps.

JacquesvanWyk on 21 Dec 2017

👎1

Having same issues as above. Set the domain to .test and also tries .app but getting connection refused.

I have ran composer global update and valet install on a computer in which I installed valet a month ago on. Now, it seems that whether valet is running or not, when I hit one of my URL's with .test all I get is "It works!" which I believe is the nginx default check.

Not sure if something got unhooked or unlinked?