Nginx

Diagnosing Nginx errors on PHP 8.2

November 17, 2023 · 3 min read

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.