Can NPM ignore nginx: [emerg] host not found in upstream error?

[denppa]

Checklist

• Have you pulled and found the error with jc21/nginx-proxy-manager:latest docker image?
  • Yes
• Are you sure you're not using someone else's docker image?
  • Yes
• Have you searched for similar issues (both open and closed)?
  • Yes

Describe the bug

Nginx Proxy Manager Version

NPM shows error at container up and won't start.

To Reproduce
Steps to reproduce the behavior:

1. back up docker compose directory data with autorestic
2. restore the exact same files with autorestic
3. restart npm
4. error log
   This is the errored line:

    proxy_pass       http://nextcloud:80/remote.php/dav;

Expected behavior

Just start right up, same container and host machine.

Screenshots
no

Operating System
ubuntu 20.04

Additional context
latest pulled docker version.

~/npm$ sudo docker compose pull
[+] Running 1/1
 ⠿ app Pulled

 "NPM_BUILD_VERSION=2.9.18",

compose file:

version: '3'
services:
  app:
    image: 'jc21/nginx-proxy-manager:latest'
    restart: unless-stopped
    ports:
      - '80:80'
      - '443:443'
      #- '81:81'
    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt
    container_name: npm

My current solution is to bomb the whole data folder and manually add back each ___domain, but that is a huge hassle, why doesn't the exact same data directory work?

EDIT:
Once I removed that conf file, the next conf files just continues to show the same error.

[denppa]

Ok, so problem is that the proxy hosts have sub directories, and those are directing to hosts that are not up at that point yet. What would be a way for nginx to wait for other docker npm to just ignore the fact that they are not resolvable and just get up?

[denppa]

Solution: use the ip address of the container so npm won't have to resolve ___domain names.

[eddywashere]

Ok, so problem is that the proxy hosts have sub directories, and those are directing to hosts that are not up at that point yet. What would be a way for nginx to wait for other docker npm to just ignore the fact that they are not resolvable and just get up?

Also ran into this. I didn't connect what exactly sub directories meant here. For others running into this issue, if you have any Custom locations or sub directories that point to a host that is down (for me it was stopped docker container on shared internal npm network) this error will occur.

It's weird that npm/nginx has no issue starting up if a host is down without custom locations. I'm not sure what makes it a required dependency only as a custom ___location.

One workaround I did was to stop npm, edit the conf file to point to a container host that was running, and then restart.

Update: Originally I did this to add access controls on specific custom locations. Switching to $server vs hostname variable fixed this as it prevents DNS resolution at boot time. Might not work for everyone but I bet this is a common enough use case to avoid downtime.

[denppa]

@eddywashere

Very clever solution, never thought I would ever had to use information in those lines of text.
Would you mind to show me how you defined the $server variable though? Is it in the text box under Advanced?

I am imagining something like this:

$server = nextcloud

[eddywashere]

@Horuyuki those 3 variables including $server in the screenshot are tied to the settings of the proxy host (set in the Details tab). So reusing $server is only helpful if it happens to be the same hostname you need to reference in the custom ___location.

If you need to define another hostname variable to reference in custom ___location(s), you do need to set it in the Advanced tab when editing Proxy Host and add something like set $custom_server nextcloud2;

You have to do it that way due to the render ordering of the conf template here

nginx-proxy-manager/backend/templates/proxy_host.conf

Line 25 in 4db34f5

{{ advanced_config }}

[poiNt3D]

Solution: use the ip address of the container so npm won't have to resolve ___domain names.

There is a problem with this solution. Docker uses dynamic ip addresses for containers and discourages using static ones.

[kabadisha]

I also had this problem. I've raised a PR which I believe fixes the issue:
#2672
If anyone on this thread can test my fix, that would be really helpful.

[SimpleUserHA]

@denppa Could this issues please be reopened or the #2672 being considered for review, since still lot's of people seem to have troubles with it.