When running a WP headless project with Node v18 (LTS) the requests to your WP from the Node server will fail.
Steps to reproduce
Create a new project (e.g. example.local)
Start example.local site.
Open a terminal
Change your Node.js version to LTS (nvm use --lts)
Run node -e "fetch('https://example.local')"
You will get an error, probably saying ECONNREFUSED.
If you run your request against the HTTP site (node -e "fetch('http://example.local')) it will succeed.
As far as I can tell, the issue is in the file /Users/[username]/Library/Application Support/Local/run/router/nginx/conf/server-block-ssl.conf
The content of this file is:
listen 443 ssl http2;
error_page 497 https://$host:$server_port$request_uri;
include includes/ssl.conf;
include includes/errors.conf;
include includes/gzip.conf;
And it is missing the directive listen [::]:443 ssl http2;.
Environment Info
Describe your environment.
What Operating System are you using? macOS Ventura 13.4
What versions of site software (Nginx, Apache, PHP, MySQL) is used? Default
This is something that was actually brought up to the team not too long ago in another channel so they are aware of it! We aren’t able to provide any kind of ETA on when this will be changed, but I just wanted to let you know that it is on the board and being looked into. You should be able to resolve this still by enabling IPv6 in the NGINX config.
Thanks for the quick reply. Do you know exactly how I could solve this in the project NGINX config?
I couldn’t find a way to modify the NGINX config for this to work. The file I mentioned is dynamically written every time the site starts.
Also, I have the feeling that when a site starts there are 2 instances of NGINX running, one with Local config and another one with the project config, and another one with the config, so if I try to define another server listening to 443 at a project level, it will cause conflict with the NGINX instance of the Local config.
Following up here after checking with our Local dev team on this. It seems like you’ve discovered a shortcoming in Local’s Nginx Router config! It’d be more noticeable in headless setups, as they utilize separate front ends to fetch data from the WordPress backend. The issue you’re seeing arises from trying to fetch over HTTPS via Node, which by default, appears to prefer IPv6.
Your hunch about the two Nginx processes running was spot on. When operating in Site Domains mode, Local uses an auxiliary Nginx server to route requests to the respective Nginx server for each site. While individual site servers are easier to manually tweak, the Router server’s configuration is embedded within the application, making it less accessible.
Currently, we don’t have a straightforward method for users to modify the Router process configuration in Local. For now, there are a couple of alternatives:
Use HTTP: Interestingly, our Router’s port 80 listener is already configured to handle IPv6. So, using HTTP could be a workaround.
Specify IPv4 in Requests: Another option would be to configure the requesting client to explicitly use IPv4.
I don’t have an ETA on a resolution but we’ve added the issue to our internal bug tracker so that we can get a fix in an upcoming release. However, keep in mind that once this is in place, you may encounter issues with Local’s use of self-signed certificates. In development, you would need to accommodate these certificates to avoid errors depending on the fetch library you use. For example, if you want to use HTTPS during the development phase, you could set the NODE_TLS_REJECT_UNAUTHORIZED=0 environment variable.
