Document a workaround for: Cannot run Local Server while something else is listening on port 443 / 80

[johnbillion]

Updated:

I have Nginx running locally. When I start Local Server I get the following error:

> composer server
Starting...
Starting docker_proxy_1 ... error

ERROR: for docker_proxy_1  Cannot start service proxy: Ports are not available: listen tcp 0.0.0.0:443: bind: address already in use

ERROR: for proxy  Cannot start service proxy: Ports are not available: listen tcp 0.0.0.0:443: bind: address already in use
ERROR: Encountered errors while bringing up the project.
Could not start traefik proxy.

I thought that I could fix this by removing the host ports from docker/proxy.yml:

       - "$PWD/sni:/etc/traefik/sni"
       - /var/run/docker.sock:/var/run/docker.sock
     ports:
-      - '8080:8080'
-      - '80:80'
-      - '443:443'
+      - '8080'
+      - '80'
+      - '443'

 networks:
   proxy:

This allows the containers to initialise using ephemeral ports on the host, however my-project.altis.dev is still being served by 127.0.0.1. Stopping my local Nginx server has no effect.

What can I do to allow an actual local server (eg. Nginx on the host machine) to run at the same time as Altis Local Server?

Task: We are going to document the workaround or troubleshooting guide to overcome this issue in the troubleshooting guide.

[nathanielks]

@johnbillion to clarify, are you able to receive traffic on the ephemeral ports?

[nathanielks]

Additionally, have you performed a search and replace on the database local-server is serving to change the siteurl to be https://my-project.altis.dev:<ephemeral-port>?

[nathanielks]

For reference, you can find what ports the reverse proxy is using on the host machine using:

docker ps -a --filter name=proxy

From there, review the ports on the 0.0.0.0 interface.

[roborourke]

@nathanielks I don't think you can specify a port when using https URLs can you?

The DNS for *.altis.dev points to 127.0.0.1 so I think that's unavoidable. I'm not sure we can support running them side by side. Is the local nginx server something you need to have running at the same time to do your work? E.g. for making requests to it for testing etc?

[nathanielks]

@roborourke aye, you can! HTTPS just defines the protocol; HTTPS can be used over any port.

[mikeselander]

A client has recently flagged this to me as being a slow-down for their dev team and a frequent issue that they have to help people track down. It would be great to get this fixed!

[roborourke]

@mikeselander do we know what other stuff they're running on those ports? There are lots of consequences to consider like how rewrites and stuff will be handled, code that's written to expect port 443 etc... Just want to know if the use case is any different to @johnbillion's

[nathanielks]

Alternatively we could add a check to the local-server scripts to check if anything is already running on those ports and fail early with the reason?

[roborourke]

my-project.altis.dev is still being served by 127.0.0.1. Stopping my local Nginx server has no effect.

Meant to ask John, what happens if you change your hosts file to point my-project.altis.dev to 0.0.0.0 and browse to that URL using the port number?

Guessing there will still be issues with the Altis codebase using things like $_SERVER['HOST_NAME'] and not handling a port number.

[roborourke]

@nathanielks I think that could help, though presumably that doesn't help when the situation is reversed. I don't think this one has a simple solution.

[nathanielks]

$_SERVER['HTTP_HOST'] will contain the port, so that should be usable.

[nathanielks]

$_SERVER['SERVER_NAME'] won't though.

[roborourke]

🤔 iiinteresting. So the Altis codebase itself (only module code) makes no reference to SERVER_NAME, only HTTP_HOST - the only potential concern is where we set the value of $_SERVER['HTTP_HOST'] for CLI contexts. So could well be simpler than I thought from that perspective after all.

@johnbillion what about proxying requests to *.altis.dev through your local nginx server to the ports that the docker proxy ends up running on?