[Support] Nginx Proxy Manager (NPM) Official


Recommended Posts

40 minutes ago, Froberg said:

curl https://192.168.1.101:444
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to 192.168.1.101:444

Does the container only support https? And are you sure it needs 444? Usually the default port for https is 443. But it is kinda inefficient to use https for local traffic. Regarding the error: I was not able to find the reason. Maybe a missing cipher?! Please use "curl -v <IP>" to get more output.

Link to comment
59 minutes ago, Froberg said:

Failed to convert 192.168.1.101 to ACE; could not convert string to UTF-8

This sounds like the IP:Port contains special chars. Are you really using "normal" numbers, dots, slashes and colon? Maybe a copy & paste problem? Please try to type everything manually. Here is an example where the user accidentally used wrong quote chars:

https://stackoverflow.com/questions/64841244/curl-put-request-content-type-header-is-not-supported

 

But in your case it seems to be a different char, which is not in the ASCII format.

Link to comment
58 minutes ago, mgutt said:

This sounds like the IP:Port contains special chars. Are you really using "normal" numbers, dots, slashes and colon? Maybe a copy & paste problem? Please try to type everything manually. Here is an example where the user accidentally used wrong quote chars:

https://stackoverflow.com/questions/64841244/curl-put-request-content-type-header-is-not-supported

 

But in your case it seems to be a different char, which is not in the ASCII format.

As nothing has been typed, both NPM and the Nextcloud container are in bridge mode, I don't see how I could input anything manually. 

The nextcloud container should forward all http requests to https. (As should NPM, by the way.) 

 

Here's doing it to the root IP: 

# curl http://192.168.1.101
<html>
<head><title>302 Found</title></head>
<body>
<center><h1>302 Found</h1></center>
<hr><center>nginx</center>
</body>
</html>

# curl https://192.168.1.101
curl: (60) SSL: no alternative certificate subject name matches target host name '192.168.1.101'
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

 

Here's connecting to the wordpress container that I set up to test - and the nextcloud docker respectively on both http and https:

# curl https://192.168.1.101:8083 
curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number
# curl http://192.168.1.101:8083
# curl https://192.168.1.101:444
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to 192.168.1.101:444 
# http://192.168.1.101:444
sh: 13: http://192.168.1.101:444: not found

 

But url's from the outside result in bad gateway though:

502 Bad Gateway

openresty

 

image.png.c6234522d6c6d99c5668e3dca3c519d8.png

 

I'm sure I'm just missing something obvious but I've tried so many different configs now that I've lost count trying to get this working again.. and it HAS been working previously. 

Link to comment
10 hours ago, Froberg said:

I set up to test - and the nextcloud docker respectively on both http and https:

Why are you testing both? Every container has a documentation (should have). As an example the original Nextcloud container supports only http:

https://hub.docker.com/_/nextcloud

"This setup provides no ssl encryption and is intended to run behind a proxy."

 

While linuxserver's version supports only https:

https://hub.docker.com/r/linuxserver/nextcloud

"Parameter Function

-p 443 WebUI"

 

Another method would be to check which internal port is used by the container. 80 is http and 443 is https.

 

So step by step. 192.168.1.101:8083 is nextcloud? Does 8083 forward to 443 or 80? Open the container config, edit this port and check the internal port. And of course tell me the repository name of the container.

 

10 hours ago, Froberg said:

As nothing has been typed, both NPM and the Nextcloud container are in bridge mode, I don't see how I could input anything manually. 

I was talking about the error "ACE; could not convert string to UTF-8" returned by curl. Your typed in IP address contained wrong chars.

 

10 hours ago, Froberg said:

# http://192.168.1.101:444

You forget "curl"

Link to comment
On 10/5/2021 at 7:10 PM, mgutt said:

It does. "not found" is an answer of the container. Try a completely different port which is not used by any container and you will see an error instead.

 

What happens if you open http://192.168.0.6:8282/ through your browser?

I am beginning to think this is just "one of these dockers" that isnt working with a proxy

 

Yes the http://192.168.0.6:8282 will provide me with the same error page

Only http://192.168.0.6:8282/youtube-dl will work

 

Yes just doing the curl for a port not in use:

image.png.cfc7fb5918b8f5ef2a6c13d38af91048.png

 

Doing it for my Bitwarden container and it shows up fine....

So some containers is just not "seen" from the NMP and these will never work?

 

Edited by casperse
Link to comment
22 minutes ago, mgutt said:

What happens if you open this in your browser? Did you try a port above 1024? Everything smaller is usually used by a different service:

https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers#Well-known_ports

 

Config has been set to disallow local logon, so connection gets refused.

Still the same result using 9444 instead of 444. 

Edited by Froberg
Link to comment
On 10/5/2021 at 8:36 PM, Froberg said:

# curl https://192.168.1.101:8083 
curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number
# curl http://192.168.1.101:8083

Ok. Then back to these tests. The first test fails because the WordPress container itself has no valid ssl certificate or does not even support https. As I did not found any information regarding https, ssl or 443 on the docs, I think it supports only http:

https://hub.docker.com/_/wordpress

 

This means you must use http to reach this container through NPM.

 

Now repeat curl <wordpress-ip:port>

 

What is the result? In your last post there was no result?!

  • Like 1
Link to comment

You are correct! When changed to http in NPM, the wordpress install is now accessible. 

That at least means that NPM works. 

So either my settings for nextcloud are off, just as they were with the wordpress install, or I guess nextcloud is just broken.. although it's updateable via command line and everything appears to function fine. 

Unless you can see anything obviously wrong, I think I'll just have to scrap the nextcloud and start over.... I do wonder what on earth has gone wrong though. 

Link to comment
1 hour ago, Froberg said:

So either my settings for nextcloud are off,

This should be the reason. Do not forget. Every traffic that is forwarded through a proxy, is coming from a local ip without any hostname (domain). This means nextcloud sees only one "visitor" with the IP of NPM, although thousands of visitors could open the domain while reaching NPM (the proxy).

 

Because of that Nextcloud allows changing several settings:

https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/reverse_proxy_configuration.html

 

The very first setting would be to add the IP of NPM as a trusted proxy. Then repeat the curl command to verify, that you are able to reach Nextcloud. Please use "curl --insecure https://<nextcloud-ip:port>". By that curl does not validate the certificate if the nextcloud container. This is important as linuxserver's container includes only a local / private certificate which can't be verified.

 

Alternatively you could use the original Nextcloud container, which is maintained in unRAID through Knex666. Add a new port like 80:8666 to use it in bridge mode and add use http in NPM as you've done with the WordPress container and it will work out of the box. But note: it needs an external database container like mariadb.

Link to comment
13 hours ago, casperse said:

Yes the http://192.168.0.6:8282 will provide me with the same error page

Only http://192.168.0.6:8282/youtube-dl will work

I'm confused. If this is the complete same behavior if you access the container through your domain (NPM container) or the local IP (YouTube container), what do you expect to happen through your domain instead?

Link to comment
1 hour ago, mgutt said:

This should be the reason. Do not forget. Every traffic that is forwarded through a proxy, is coming from a local ip without any hostname (domain). This means nextcloud sees only one "visitor" with the IP of NPM, although thousands of visitors could open the domain while reaching NPM (the proxy).

 

Because of that Nextcloud allows changing several settings:

https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/reverse_proxy_configuration.html

 

The very first setting would be to add the IP of NPM as a trusted proxy. Then repeat the curl command to verify, that you are able to reach Nextcloud. Please use "curl --insecure https://<nextcloud-ip:port>". By that curl does not validate the certificate if the nextcloud container. This is important as linuxserver's container includes only a local / private certificate which can't be verified.

 

Alternatively you could use the original Nextcloud container, which is maintained in unRAID through Knex666. Add a new port like 80:8666 to use it in bridge mode and add use http in NPM as you've done with the WordPress container and it will work out of the box. But note: it needs an external database container like mariadb.

 

It's already using MariaDB. 

I had a problem with my cache drive, everything went down, turns out it was the database, but I hadn't suspected that before fiddling with NPM first, as that had just been updated and I noticed things not working post-updating that, rather than when MariaDB updated. 

So not sure what exactly happened, but Nextcloud was working perfectly with the config it had. I have to assume that maybe something got corrupted, despite its services being functional. 

I'll have a look at the Knex-container as you recommended. I've gotten this stuff to work before, I just ran against a wall trying to debug this and, well, finding a clue when you're frustrated isn't easy.

I really appreciate you taking the time, thank you so much! 

Link to comment

After many long hours of troubleshooting and learning, I have put together a configuration that gets NPM, Nextcloud, and iOS all playing nicely.

 

  1. Create a proxy host
  2. Input domain name (nextcloud.example.com)
  3. Scheme: https
  4. Forward Hostname / IP*: whatever your endpoint is
  5. Forward Port: 443 or whatever https port you are using
  6. Check "Block Common Exploits" and "Websockets Support"
  7. Click SSL
  8. Obtain new SSL cert, and check boxes for "Force SSL", "HTTP/2 Support", "HSTS Enabled", and "HSTS Subdomains"
  9. Click Advanced
  10. Input the following into entry box:

    proxy_hide_header Upgrade;
    proxy_max_temp_file_size 1024000m;
    
    proxy_next_upstream error timeout invalid_header http_500 http_502 http_503;
    
    proxy_buffers 32 4k;
    proxy_connect_timeout 240;
    proxy_headers_hash_bucket_size 128;
    proxy_headers_hash_max_size 1024;
    proxy_read_timeout 240;
    proxy_redirect  http://  $scheme://;
    proxy_send_timeout 240;
    
    proxy_cache_bypass $cookie_session;
    
    proxy_no_cache $cookie_session;
    proxy_set_header Early-Data $ssl_early_data;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Forwarded-Proto https;
    proxy_set_header X-Forwarded-Ssl on;
    proxy_set_header X-Real-IP $remote_addr;
    
  11. Save!

Hope this helps. FYI, I put this together referencing the nextcloud.subdomain.conf.sample and proxy.conf in SWAG's configuration files.

Link to comment
3 hours ago, Hackintosys said:

should my domain itself be ssl encrypted also?

This is not possible. The SSL certificate is located on the server. If you would buy an SSL certificate you would need to store it on the nginx server, so you would use it instead of the let's encrypt certificate.

Link to comment
15 minutes ago, mgutt said:

Additional rules can only be applied through the advanced tab of a host. You can't modify the files directly.

I don't need to add additional rules, the log_format is invalid for Argo Tunnel
I can not modify the log_format via advanced.

 

I was able to find the files in console shell for the container (which will retain changes until I update the docker). debian-buster slim is nice.

Link to comment
1 hour ago, fmp4m said:

I was able to find the files in console shell for the container

You could try to mount the paths to your local host, but you need to copy the existing files then. By that they would be in your appdata folder which would survive a container update.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.