Some people running the Valet v4 beta get ERR_NGROK_8012 when trying to share with ngrok

[mattstauffer]

Thanks for reports from @nicoverbruggen, @dcblogdev, @ashleyshenton.

Hoping @caseysoftware can help me debug this!

[caseysoftware]

We've kicked this around internally to track it down.

Basically, ERR_NGROK_8012 means the local ngrok agent started successfully but can't connect to the service you assigned it. Most commonly this happens because:

• the service isn't running (that doesn't look like the case here)
• the service can't be found (likely)

I'd start with the DNS entry. As a test, you could set it in /etc/hosts to see if that maps it. Then we can confirm that it's neither ngrok nor the service and isolate it to the local proxy.

If it's the local proxy - nginx, I assume? - I'd check the sites-enabled folder to make sure that the url is set and the proxy is properly configured.

[ashleyshenton]

Okay, so the tunnel works when I add a reference to my /etc/hosts file.

This is the line I added to the hosts file 127.0.0.1 huler-poc.test

And this is to be expected but I also had to add the following to my .env in order for the assets to load.

APP_URL=https://cb32-216-205-160-212.eu.ngrok.io
ASSET_URL="${APP_URL}"

[mattstauffer]

The local proxy is nginx (and dnsmasq). But we don't add the sites to sites-enabled.

The individual sites where we've done custom config (e.g. valet secure) live here:

~/.config/valet/Nginx/{sitename.tld}

Their config files are built from one of these stubs:

• https://github.com/laravel/valet/blob/master/cli/stubs/valet.conf
• https://github.com/laravel/valet/blob/master/cli/stubs/site.valet.conf
• https://github.com/laravel/valet/blob/master/cli/stubs/secure.valet.conf

Then we publish one master Nginx configuration file to BREW_PREFIX/etc/nginx/nginx.conf that serves 99% of sites. Here's what that file looks like:

https://github.com/laravel/valet/blob/master/cli/stubs/nginx.conf

[mattstauffer]

@laytan would you mind double checking something for me? I don't think I've made any changes to Nginx lately, but would you mind running valet install and then testing a site again (not the one you did the tweaks above to) just so I can make sure it's not something where you have an out-of-date config file?

Thanks!

[mattstauffer]

@laytan oo also--would you try securing a site and make sure it also has the same problem? Thanks!

[ashleyshenton]

@mattstauffer were those messages intended for me? Either way, I tested them. After a valet install, the same issue occurs.

I have removed the /etc/hosts reference above and used the same project. I ran valet secure and it is now served over https with no issues using the local .test TLD. However, the same issues occur when using valet share. The only difference you will notice is the port referenced. It is 60 instead of the 80 shown in my original image.

[laytan]

@mattstauffer Wrong tag I think, I haven't been part of this issue.

[mattstauffer]

@ashleyshenton and @laytan lol... i'm so sorry... been chatting with @laytan on a different issue and just got y'all mixed up.

@ashleyshenton Thanks so much for running those checks!

[mattstauffer]

I tried as hard as I could to break my setup and reproduce this but haven't been able to so far. Anyone have any ideas about next steps? Is anyone having this issue available to possibly meet up with @caseysoftware or anyone on the ngrok team to help them debug it with you?

[nicoverbruggen]

I was able to fix this by going into my network connection in System Settings (System Preferences on Monterey and earlier), and adding 127.0.0.1 to my DNS servers so dnsmasq is the first to resolve the custom domain, like so:

Basically, I read the explanation here and applied the same logic to my local networking setup.

Without specifying 127.0.0.1 as the DNS server I did not get this working before, with or without other custom DNS servers. (I usually use Cloudflare's DNS server instead of my ISP's.)

[caseysoftware]

So "it's always DNS" strikes again :|

[ashleyshenton]

I can confirm that after making the changes suggested by @nicoverbruggen that this also works for me now.

[caseysoftware]

I've been messing around with this one too and got the same result. DNS resolution has to start with dnsmasq or it's going to go out to a general one and not find the underlying server.

Is there a way to force 127.0.0.1 into the order without a manual step?

At present, this is outside of ngrok but happy to brainstorm on approaches and debugging.

[mattstauffer]

@caseysoftware Thanks so much! I'm not sure, but I am surprised this is new in this release of Valet. Is there any chance your team knows about any changes that have been made to ngrok since the version we were shipping before that may have introduced this? It's totally fine if so, but would at least give me some peace that i didnt' accidentally introduce this issue.

[irazasyed]

Just came here to say @nicoverbruggen's solution works. Should've checked this issue earlier, spent an hour trying to figure out what went wrong with my setup 😂

[caseysoftware]

We dug into this one again from our side and found an issue with macOS arm64.

It's resolved in v3.2.1 of the ngrok agent and since you install ngrok via Brew, this issue should go away completely.

Thanks for all your hard work @mattstauffer!

[caseysoftware]

And another followup..

In v3.3.0 of the ngrok agent last month, we expanded ngrok diagnose to warn users if they're hitting this localhost DNS issue.

Thanks again for highlighting it!