Upon testing some new functionality locally, I noticed that I was getting my favorite error, 502 Bad Gateway.
I had a look at the error logs in ~/.config/valet/Log/nginx-error.log and found this grouping of errors:
2023/11/17 13:42:09 [error] 89485#0: *1 connect() to unix:/Users/jbrayton/.config/valet/valet.sock failed (61: Connection refused) while connecting to upstream, client: 127.0.0.1, server: stripe-sync.test, request: "GET / HTTP/2.0", upstream: "fastcgi://unix:/Users/jbrayton/.config/valet/valet.sock:", host: "stripe-sync.test"
2023/11/17 13:43:21 [error] 89483#0: *12 connect() to unix:/Users/jbrayton/.config/valet/valet.sock failed (61: Connection refused) while connecting to upstream, client: 127.0.0.1, server: stripe-sync.test, request: "GET / HTTP/2.0", upstream: "fastcgi://unix:/Users/jbrayton/.config/valet/valet.sock:", host: "stripe-sync.test"
2023/11/17 13:45:54 [error] 89476#0: *44 connect() to unix:/Users/jbrayton/.config/valet/valet.sock failed (61: Connection refused) while connecting to upstream, client: 127.0.0.1, server: stripe-sync.test, request: "GET / HTTP/2.0", upstream: "fastcgi://unix:/Users/jbrayton/.config/valet/valet.sock:", host: "stripe-sync.test"
2023/11/17 13:51:39 [error] 89471#0: *49 connect() to unix:/Users/jbrayton/.config/valet/valet.sock failed (61: Connection refused) while connecting to upstream, client: 127.0.0.1, server: larajobs-menubar.test, request: "GET / HTTP/2.0", upstream: "fastcgi://unix:/Users/jbrayton/.config/valet/valet.sock:", host: "larajobs-menubar.test"I performed a generic Google search for nginx "*12 connect()" to unix
Nothing hit me directly but it did highlight the excellent primer on Datadog NGINX 502 Bad Gateway: PHP-FPM
I ran valet links to get a list of other sites to try to see if this was isolated to a PHP version and it was, PHP 8.2 was the only one having problems.
I had tried valet restart and valet restart php but that didn't help.
I wanted to check the status of services to make sure they were running and we can do that via valet status:
Checking status...
Valet status: Error
+--------------------------------------+----------+
| Check | Success? |
+--------------------------------------+----------+
| Is Valet fully installed? | Yes |
| Is Valet config valid? | Yes |
| Is Homebrew installed? | Yes |
| Is DnsMasq installed? | Yes |
| Is Dnsmasq running? | Yes |
| Is Dnsmasq running as root? | Yes |
| Is Nginx installed? | Yes |
| Is Nginx running? | Yes |
| Is Nginx running as root? | Yes |
| Is PHP installed? | Yes |
| Is linked PHP (php) running? | No |
| Is linked PHP (php) running as root? | No |
| Is valet.sock present? | Yes |
+--------------------------------------+----------+
Debug suggestions:
Run `valet restart`.
Uninstall PHP with Brew and run `valet use php@8.2`I ended up using valet use php@8.2 --force in the end:
⋊> brew uninstall php
Error: Refusing to uninstall /usr/local/Cellar/php/8.2.11
because it is required by composer, php-cs-fixer and wp-cli, which are currently installed.
You can override this and force removal with:
brew uninstall --ignore-dependencies php
⋊> valet use php@8.2
Valet is already using version: php@8.2. To re-link and re-configure use the --force parameter.
⋊> valet use php@8.2 --force
Unlinking current version: php
Linking new version: php@8.2
Stopping phpfpm...
Stopping php@7.2...
Stopping php@8.1...
Installing and configuring phpfpm...
Updating PHP configuration for php@8.2...
Restarting php@8.1...
Restarting php@7.1...
Restarting php@7.4...
Restarting php@7.2...
Restarting php@7.3...
Restarting php...
Restarting nginx...
Valet is now using php@8.2.
Note that you might need to run composer global update if your PHP version change affects the dependencies of global packages required by Composer.The stop messages not aligning with the restarts is particularly interesting and likely part of what I was dealing with. I hadn't tried sites tied to each version independently.
Recently, after a brief outage at work, I wondered if it would be possible to replicate the problem locally using Laravel Valet. My Google search landed on this StackOverflow post, where the answers shot down the idea. Not to be dissuaded by something I read on the internet, I started investigating if it was possible and stumbled upon what I think is a viable solution. There aren't very many hoops to jump through or major quirks so I believe it's not only possible but could be supported out of the box.
In my case, I want to proxy the domain scdn-app.thinkorange.com through my local version of the Laravel application.
~/.config/valet/config.json on macOS and change the tld parameter from test to com.valet link scdn-app.thinkorange to set up our valet configuration to point the domain to this directory.valet secure scdn-app.thinkorange to set up the SSL certificate.cd ~/.config/valet/dnsmasq.d.cp tld-test.conf tld-com.conf.address=/.com/127.0.0.1 and save the file.valet isolate --site scdn-app.thinkorange php@8.1./etc/hosts file to redirect the domain to 127.0.0.1 for ipv4 and ::1. I use the excellent Gas Mask to make this step easier.Now we should have a functional production proxy through our local machine. This configuration creates a few problems around keeping the com TLD.
Fortunately, a few extra steps are necessary for us to switch back to .test while also keeping this site functional.
~/.config/valet/config.json again and change the tld parameter from com back to test. This change will immediately break our site.cd ~/.config/valet/Sites.ls -al to list the directory, we'll see our site scdn-app.thinkorange. Let's change that.mv scdn-app.thinkorange scdn-app.thinkorange.com.Our site should now be working again. We are also able to continue serving our previous local test domains.
Because we can create a permanently functional system using these steps, I believe it should be possible to create a pull request to reduce the number of hoops we have to jump through.
I'd love to be able to run valet link scdn-app.thinkorange.com. with a period at the end to denote I'm including the full domain with TLD.
That would eliminate the temporary step of editing the config.json file, and the Sites directory would just work(TM) as it would include the .com directory name.
I don't believe we even need the dnsmasq changes as I'm able to navigate to a functional site without them.
I believe Gas Mask is doing the work, but it's better to be safe than sorry.
If you'd prefer a YouTube video where I stumble through recreating these steps from scratch: