[Bug]: Connection refused behind proxy

[leonharv]

Checklist

• [X] The issue exists after disabling all extensions
• [X] The issue exists on a clean installation of webui
• [ ] The issue is caused by an extension, but I believe it is caused by a bug in the webui
• [X] The issue exists in the current version of the webui
• [X] The issue has not been reported before recently
• [ ] The issue has been reported before but has not been fixed yet

What happened?

I try to run the webui behind a reverse proxy. The website loads, but the websocket connection still points to ws://127.0.0.1:7860. Thus I get error messages.

Steps to reproduce the problem

I use the following command:

$ ./webui.sh --server-name foo

What should have happened?

I expect that by passing the --server-name argument, that the websocket connection should use this too.

What browsers do you use to access the UI ?

Mozilla Firefox

Sysinfo

no need for a sysinfo.

Console logs

no logs needed.

Additional information

A current workaround is to use an additional parameter --no-gradio-queue to disable the websocket connections.

[w-e-w]

this was quite a long time ago and it's quite a while I played around with networking I remember when I was testing reverse proxy I configured it by using --subpath I don't recall using --server-name only --listen whitch sets the host to be 0.0.0.0

--subpath was implemented long ago but I think I forgot to add it to the wiki Command-Line-Arguments-and-Settings

but since it works for you --no-gradio-queue I don't think --subpath is revelant so I'm not exactly sure what's going on

[leonharv]

Looks like --listen changes the websocket connection to localhost or whatever one is accessing the server. In my setting, this is fine. However, I needed to adjust the reverse proxy to forward the websocket connections.

Thank you for your input.

I guess the issue is still present, but as long as --listen and --no-gradio-queue works, the issue is minor.

PS: I understood --subpath in the sense of a URI, i.e. http://localhost/subpath.

[w-e-w]

did some quick search and it seems that some reverse proxy may not support WebSocket or it requires extra configuration to allow WebSocket if this is case then this is a configuration issue on your side depending on the specific reverse proxy server you're using

---

I needed to adjust the reverse proxy to forward the websocket connections.

lol, didn't read that

[w-e-w]

--no-gradio-queue I recall made disable some functionality for example sometimes we send info warning or error message using Gradio.Info it would basically show up as a pop up on the top right corner of the web page

with --no-gradio-queue this type of message won't be able to show this is just messages so it's recently less important but they might be some other things that critical relies on websockets, I just can't think of one on the top of my head

[leonharv]

I see. I also saw the error messages in the logs of the browser.

If I understand you correctly, the error of the websocket connection has nothing to do with the core functionalit?

However, I have everything running now behind a reverse proxy. Thank you for your help.