[GH-ISSUE #5] more setting request #5

Closed
opened 2026-02-26 05:32:56 +03:00 by kerem · 5 comments
Owner

Originally created by @NoName805 on GitHub (Jul 25, 2018).
Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/5

Could you please add some settings as below config?

Because I have no idea to forward my site to my back-end https server? --> proxy_pass https://x.x.x.x/;.

I just modify the config file as below for make my site work now.

   location / {
	proxy_pass https://x.x.x.x/;
	proxy_http_version      1.1;
        proxy_set_header Connection "";
	proxy_read_timeout      360;
	proxy_pass_header       Date;
	proxy_pass_header       Server;
	proxy_pass_header       Authorization;
	proxy_set_header        Host $host;
	proxy_set_header        X-Real-IP $remote_addr;
	proxy_set_header        X-Forwarded-For  $proxy_add_x_forwarded_for;
	proxy_pass_request_headers on;
	proxy_set_header Accept-Encoding "";
	proxy_request_buffering off;
	proxy_buffering off;
	#proxy_set_header Connection "Keep-Alive";
	}

Many thanks.

Originally created by @NoName805 on GitHub (Jul 25, 2018). Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/5 Could you please add some settings as below config? Because I have no idea to forward my site to my back-end https server? --> proxy_pass https://x.x.x.x/;. I just modify the config file as below for make my site work now. location / { proxy_pass https://x.x.x.x/; proxy_http_version 1.1; proxy_set_header Connection ""; proxy_read_timeout 360; proxy_pass_header Date; proxy_pass_header Server; proxy_pass_header Authorization; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass_request_headers on; proxy_set_header Accept-Encoding ""; proxy_request_buffering off; proxy_buffering off; #proxy_set_header Connection "Keep-Alive"; } Many thanks.
kerem 2026-02-26 05:32:56 +03:00
Author
Owner

@jc21 commented on GitHub (Jul 25, 2018):

I do want to improve the functionality while maintaining an easy to understand interface. I think giving the ability to modify the config within the site will be the best option for this. It's pretty hard to support websockets upgrade for example as nearly every different site puts that in a different subpath.

<!-- gh-comment-id:407916630 --> @jc21 commented on GitHub (Jul 25, 2018): I do want to improve the functionality while maintaining an easy to understand interface. I think giving the ability to modify the config within the site will be the best option for this. It's pretty hard to support websockets upgrade for example as nearly every different site puts that in a different subpath.
Author
Owner

@SGStino commented on GitHub (Sep 28, 2018):

Perhaps the advanced configuration should by default show the entire server { } configuration contents, just automatically generated, and the variables from the first tab provided as $variables?

(so basically move the location / { } to the advanced configuration by default?)
As long as nobody goes to the advanced tab, it's still simple to use, but also more powerfull for more experienced users?

So far i've been able to do the websockets for most scenarios, except now for mosquitto. Where the root seems to be the websocket path.

<!-- gh-comment-id:425382789 --> @SGStino commented on GitHub (Sep 28, 2018): Perhaps the advanced configuration should by default show the entire `server { }` configuration contents, just automatically generated, and the variables from the first tab provided as $variables? (so basically move the `location / { }` to the advanced configuration by default?) As long as nobody goes to the advanced tab, it's still simple to use, but also more powerfull for more experienced users? So far i've been able to do the websockets for most scenarios, except now for mosquitto. Where the root seems to be the websocket path.
Author
Owner

@jc21 commented on GitHub (Sep 29, 2018):

Yep I considered that as an option. In your case, it might be worth adding a option to enable websocket upgrades for the entire site, as the quickest solution. I've been considering that anyway and no reason why both ideas can't co-exist. I'll look in to it in a week

<!-- gh-comment-id:425616407 --> @jc21 commented on GitHub (Sep 29, 2018): Yep I considered that as an option. In your case, it might be worth adding a option to enable websocket upgrades for the entire site, as the quickest solution. I've been considering that anyway and no reason why both ideas can't co-exist. I'll look in to it in a week
Author
Owner

@jc21 commented on GitHub (Oct 1, 2018):

This doesn't solve the original issue, but I've added another setting for Proxy Hosts in version 2.0.3 for any hosts that need websocket upgrades. Just turn on "Allow Websocket HTTP Upgrades" and hopefully everything works without the need for advanced config.

<!-- gh-comment-id:426086211 --> @jc21 commented on GitHub (Oct 1, 2018): This doesn't solve the original issue, but I've added another setting for Proxy Hosts in version 2.0.3 for any hosts that need websocket upgrades. Just turn on "Allow Websocket HTTP Upgrades" and hopefully everything works without the need for advanced config.
Author
Owner

@chaptergy commented on GitHub (May 10, 2021):

As custom nginx configuration for hosts and locations are possible, I think this issue does not have to stay open anymore.

<!-- gh-comment-id:837071289 --> @chaptergy commented on GitHub (May 10, 2021): As custom nginx configuration for hosts and locations are possible, I think this issue does not have to stay open anymore.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/nginx-proxy-manager-NginxProxyManager#5
No description provided.