I’ve run into a few issues with websockets and proxying, and need a little help understanding the why so I can figure out a fix. I don’t like changing stuff manually unless needed; config files and such. I’d much rather let VMin handle the backend stuff so I don’t screw things up. So my Virtualmin setup is a basic virtualmin-install, with the only manually modified file relating to virtualmin-switch-user-on-cd.
When playing around with Code-Server, and now Immich, I have noticed that the web socket connections fail unless I modify the sites-available/MyDomain.conf files through Edit Directives. This happens when using Edit Proxy Website, as well as the Proxy Paths options. I found a solution here, but there were no replies, and no explanations on why this was happening.
I’ve added RewriteEngine on to the Configure SSL Website directives, and thus have the websockets working in Chrome/Brave. When I was just worried about modifying the code-server directives, I simply used Brave; as mentioned, I don’t like hand changing files. However, this really isn’t a viable solution since I prefer Firefox and now I can’t get Immich to properly connect sockets without modifying the RewriteCond %{HTTP:CONNECTION} Upgrade [NC] code as well.
The pic below explains my issues. Server Online is a Brave window, Server Offline is a FF window.
Please explain the following: Is this a bug? Is there a reason the RewriteEngine directive isn’t in the SSL config? Is manually changing the Upgrade line the proper way of doing things, or should I do something else? Is there a better way to handle anything I’ve discussed?
Not a bug. You just have different requirements from what the Proxy Paths feature sets up. I’m not sure it’s possible to accommodate every possible proxy configuration.
But, we probably should accommodate websockets somehow, maybe via an option.
@Jamie can we give a little more flexibility in the Proxy Paths page, to allow for WebSockets, at least, though I think there are also other configurations we’re not allowing.
Manually configuring things is fine; I wouldn’t try to start with the Proxy Paths module generated directives if you’re going to change them, though. Just do it all yourself. Virtualmin isn’t going to overwrite or mess it up when you make changes later to unrelated stuff, as long as it doesn’t think it’s responsible for it, it parses the config file.
Sorry guys… work weekends so getting back to the forums is sporadic. @Jamie is correct I believe. There is a web socket checkbox in the Proxy Paths section of VMin.
However, without adding RewriteEngine on in the SSL config, the web socket connection doesn’t work for any browser. In addition, I have to alter the following to get web sockets working in Firefox specifically. However, after making this change the connection works in all browsers I’ve tried.
RewriteCond %{HTTP:CONNECTION} ^Upgrade$ [NC] to
RewriteCond %{HTTP:CONNECTION} Upgrade [NC]
This is the case when using both the Proxy Paths configuration with the WS checkbox checked, as well as using the Edit Proxy Website (where there is no web socket checkbox).
Is there a reason the RewriteEngine directive isn’t in the SSL config? @Jamie, if the following doesn’t answer your questions let me know. I’ll try to get on again tonight and tomorrow to make sure you have everything you need. Thx!
Pertinent code-server SSL Configuration
ProxyPass /.well-known !
ProxyPass / http://localhost:8443/
RemoveHandler .php
RemoveHandler .php8.2
<FilesMatch \.php$>
SetHandler proxy:unix:/run/php/17528436052465287.sock|fcgi://127.0.0.1
</FilesMatch>
SSLEngine on
RewriteEngine on *######## This is the only Manual change I made*
SSLCertificateFile /etc/ssl/virtualmin/17528436052465287/ssl.cert
SSLCertificateKeyFile /etc/ssl/virtualmin/17528436052465287/ssl.key
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
SSLCACertificateFile /etc/ssl/virtualmin/17528436052465287/ssl.ca
ProxyPassReverse / http://localhost:8443/
RewriteCond %{HTTP:UPGRADE} ^WebSocket$ [NC]
RewriteCond %{HTTP:CONNECTION} ^Upgrade$ [NC]
RewriteRule ^/?(.*) "ws://localhost:8443/$1" [P]
Pertinent immich SSL Configuration
ProxyPass /.well-known !
ProxyPass / http://localhost:2283/
RemoveHandler .php
RemoveHandler .php8.2
<FilesMatch \.php$>
SetHandler proxy:unix:/run/php/1755161458149441.sock|fcgi://127.0.0.1
</FilesMatch>
SSLEngine on
RewriteEngine on *######## This is the first Manual change I made*
SSLCertificateFile /etc/ssl/virtualmin/1755161458149441/ssl.cert
SSLCertificateKeyFile /etc/ssl/virtualmin/1755161458149441/ssl.key
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
SSLCACertificateFile /etc/ssl/virtualmin/1755161458149441/ssl.ca
ProxyPassReverse / http://localhost:2283/
RewriteCond %{HTTPS} off
RewriteCond %{HTTP:UPGRADE} ^WebSocket$ [NC]
RewriteCond %{HTTP:CONNECTION} Upgrade [NC] *######## This is the second Manual change I made*
RewriteRule ^/(?!.well-known)(.*)$ https://%{HTTP_HOST}/$1 [R]
RewriteRule ^/?(.*) "ws://localhost:2283/$1" [P]
ADDITIONAL: I should also note that each of these config files are for sub-servers. I just created a test sub-server that is proxied to localhost:98765 to get the default generated SSL config file attached below. No modifications have been made manually.
Which Virtualmin version are you on there? Because some older releases did use ^Upgrade$ instead of Upgade, but we fixed that in the most recent release.
The info in the top box is all the current information.
Webmin version
2.402
Virtualmin version
7.30.8 Pro
On phone, so can’t easily navigate to recheck. This setup is is a complete reinstall with all new downloads as of June 20, 2025. Some domains are from backups from a previous VM install dating Oct 01, 2024. All subdomains are new and not from backups. Also, domains created from scratch (not backups transferred over) on the June setup still have the old ^Upgrade$ code and are missing RewriteEngine on.
Ok I looked into this some more, and found a bug that was preventing Virtualmin from adding RewriteEngine on when needed .. we’ll fix this in the next release.
As for the issue with the Upgrade option still using ^Upgrade$ , this is definitely fixed in our latest unreleased code. So that will also be resolved in the next relase, due out in a couple of days.
This is great news. I appreciate the quick response and information. After the next release is pushed, will the scripts correct the missing/improper lines when rerunning Check VMin Configuration, or will it only function properly on new server creations? Should I modify the lines now, or will that cause issues when the scripts run?
