Nginx server is not listening for HTTPS IPv6 requests

Bugs
5

Hey @Orballo!

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:

  1. Use HTTP: Interestingly, our Router’s port 80 listener is already configured to handle IPv6. So, using HTTP could be a workaround.

  2. 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.