+10
Started

Bad Request (Invalid host) after upgrading to CWC v19.5

gil.pdo 4 months ago updated by frufru 2 months ago 48

I've been upgrading from older versions to the most recent stable version for the past 4 years without any problems but the upgrade from version 19.4 to 19.5 broke my server access. When I try to access my site I get this error: 

Bad Request (Invalid host)

I'm running Ubuntu Server 16.04.6 LTS

I took a snapshot before the upgrade and I was able to back to version 19.4 without any problems.

I would love to upgrade to version 19.5 but I don't why it's not working like before anymore.

ConnectWise Control Version:
19.5
Server Affected:
Host Client Affected:
Guest Client Affected:

I'm facing the same issue, I can confirm if I access via the IP address it loads, but if I access via the hostname it does not.

We also had the following error during upgrade.

The service now manually starts, but only accessible via the IP

Running 'Stop existing service screenconnect if running'...
Running 'Remove startup links pointing to script at /etc/init.d/screenconnect'...
Running 'Remove service start script at /etc/init.d/screenconnect'...
Running 'Remove startup links with update-rc.d'...
Running 'Back up the existing configuration'...
Running 'Create service script at /etc/init.d/screenconnect'...
Running 'Create startup links in /etc/rcX.d/ directories'...
Running 'Update startup links with update-rc.d'...
Running 'Copy files into /opt/screenconnect'...
Running 'Restore backed up configuration'...
Running 'Transform configuration files'...

Unhandled Exception:
System.Xml.Xsl.XslTransformException: Attribute and namespace nodes cannot be added to the parent element after a text, comment, pi, or sub-element node has already been added.
at System.Xml.Xsl.Runtime.XmlQueryOutput.ThrowInvalidStateError (System.Xml.XPath.XPathNodeType constructorType) [0x000cf] in :0
at System.Xml.Xsl.Runtime.XmlQueryOutput.ConstructInEnumAttrs (System.Xml.XPath.XPathNodeType rootType) [0x0001f] in :0
at System.Xml.Xsl.Runtime.XmlQueryOutput.WriteStartAttribute (System.String prefix, System.String localName, System.String ns) [0x0001e] in :0
at System.Xml.Xsl.Runtime.XmlQueryOutput.WriteStartAttributeLocalName (System.String localName) [0x00000] in :0
at (wrapper dynamic-method) System.Object.(System.Xml.Xsl.Runtime.XmlQueryRuntime,System.Xml.XPath.XPathNavigator)
at (wrapper dynamic-method) System.Object.(System.Xml.Xsl.Runtime.XmlQueryRuntime,System.Xml.XPath.XPathNavigator)
at (wrapper dynamic-method) System.Object.(System.Xml.Xsl.Runtime.XmlQueryRuntime,System.Xml.XPath.XPathNavigator)
at (wrapper dynamic-method) System.Object.(System.Xml.Xsl.Runtime.XmlQueryRuntime,System.Xml.XPath.XPathNavigator)
at (wrapper dynamic-method) System.Object.Root(System.Xml.Xsl.Runtime.XmlQueryRuntime)
at (wrapper dynamic-method) System.Object.Execute(System.Xml.Xsl.Runtime.XmlQueryRuntime)
at System.Xml.Xsl.XmlILCommand.Execute (System.Object defaultDocument, System.Xml.XmlResolver dataSources, System.Xml.Xsl.XsltArgumentList argumentList, System.Xml.Xsl.Runtime.XmlSequenceWriter results) [0x00020] in :0
at System.Xml.Xsl.XmlILCommand.Execute (System.Object defaultDocument, System.Xml.XmlResolver dataSources, System.Xml.Xsl.XsltArgumentList argumentList, System.Xml.XmlWriter writer) [0x0004f] in :0
at System.Xml.Xsl.XslCompiledTransform.Transform (System.Xml.XmlReader input, System.Xml.Xsl.XsltArgumentList arguments, System.Xml.XmlWriter results, System.Xml.XmlResolver documentResolver) [0x0000d] in :0
at System.Xml.Xsl.XslCompiledTransform.Transform (System.String inputUri, System.Xml.Xsl.XsltArgumentList arguments, System.IO.Stream results) [0x00029] in :0
at Xsl.Program.Main (System.String[] args) [0x0007b] in :0
[ERROR] FATAL UNHANDLED EXCEPTION: System.Xml.Xsl.XslTransformException: Attribute and namespace nodes cannot be added to the parent element after a text, comment, pi, or sub-element node has already been added.
at System.Xml.Xsl.Runtime.XmlQueryOutput.ThrowInvalidStateError (System.Xml.XPath.XPathNodeType constructorType) [0x000cf] in :0
at System.Xml.Xsl.Runtime.XmlQueryOutput.ConstructInEnumAttrs (System.Xml.XPath.XPathNodeType rootType) [0x0001f] in :0
at System.Xml.Xsl.Runtime.XmlQueryOutput.WriteStartAttribute (System.String prefix, System.String localName, System.String ns) [0x0001e] in :0
at System.Xml.Xsl.Runtime.XmlQueryOutput.WriteStartAttributeLocalName (System.String localName) [0x00000] in :0
at (wrapper dynamic-method) System.Object.(System.Xml.Xsl.Runtime.XmlQueryRuntime,System.Xml.XPath.XPathNavigator)
at (wrapper dynamic-method) System.Object.(System.Xml.Xsl.Runtime.XmlQueryRuntime,System.Xml.XPath.XPathNavigator)
at (wrapper dynamic-method) System.Object.(System.Xml.Xsl.Runtime.XmlQueryRuntime,System.Xml.XPath.XPathNavigator)
at (wrapper dynamic-method) System.Object.(System.Xml.Xsl.Runtime.XmlQueryRuntime,System.Xml.XPath.XPathNavigator)
at (wrapper dynamic-method) System.Object.Root(System.Xml.Xsl.Runtime.XmlQueryRuntime)
at (wrapper dynamic-method) System.Object.Execute(System.Xml.Xsl.Runtime.XmlQueryRuntime)
at System.Xml.Xsl.XmlILCommand.Execute (System.Object defaultDocument, System.Xml.XmlResolver dataSources, System.Xml.Xsl.XsltArgumentList argumentList, System.Xml.Xsl.Runtime.XmlSequenceWriter results) [0x00020] in :0
at System.Xml.Xsl.XmlILCommand.Execute (System.Object defaultDocument, System.Xml.XmlResolver dataSources, System.Xml.Xsl.XsltArgumentList argumentList, System.Xml.XmlWriter writer) [0x0004f] in :0
at System.Xml.Xsl.XslCompiledTransform.Transform (System.Xml.XmlReader input, System.Xml.Xsl.XsltArgumentList arguments, System.Xml.XmlWriter results, System.Xml.XmlResolver documentResolver) [0x0000d] in :0
at System.Xml.Xsl.XslCompiledTransform.Transform (System.String inputUri, System.Xml.Xsl.XsltArgumentList arguments, System.IO.Stream results) [0x00029] in :0
at Xsl.Program.Main (System.String[] args) [0x0007b] in :0
Running 'Start screenconnect service'...

Installation complete!

Could you guys send me your web.config files before and after the upgrade? Not seeing a specific reference in that exception message. (edavis@connectwise.com)

I have the same issue, running in AWS, on ubuntu, no file changes in web config, i will send you my web.config file

Facing the same exact issue on Ubuntu 18.04. Using Nginx as reverse proxy.

I'm running v19.5 with an nginx reverse proxy on Ubuntu 18.04 LTS. It works for me as of this morning.


Here is my nginx config: FQDN.conf

Tried using this file but still getting Bad Request (Invalid host). I suspect it's something in web.config. I have sent a copy for Eric to take a look at.

Here is my web.config file: web.config

I've hopefully removed any private details.

+2

@TechCare Thank you sir, looks like I managed to get it going. 

In case anyone is interested I changed WebServerListenUri line only from "http://0.0.0.0:8118/" to "http://+:8118/"

After this everything works as expected.

+1

I'm happy that worked for you


my Uri already had the +, and I am still unable to connect after the upgrade, I have submitted my web.config to Eric Davis as well.

any new status for this issue.

I to enjoy the flawless install but, i have tried a few things suggested here and
same thing every time.

Upon checking the download link today

https://www.connectwise.com/software/control/download

I noticed the Linux version 19.5.26030.7282 was removed from the download link. Finally, the developers realized that this so-called "stable" release wasn't stable at all. Let's hope the next version will fix this for all.

I noticed that as well.
possibly this weekend, that would be great.

I forgive them, cant always bat 100

any update on a new stable version for Linux ?

The more people that vote on a bug the more attention it will draw. So vote people vote.


@Vladimir - the way this works is we hear nothing. One day it will come.


They could learn a lot from the guys over at Ubiquiti Forums who are hourly responding to their users. Especially in the Beta forums.


It doesn't have to be like this.

This seems to be working now after an update and a webconfig change removing the ip address from the listening uri and adding a +.

Yes, it's working now. I did this change before updating to the new version just to make sure my old version would still work. I only had to change the web.config. No changes were necessary on nginx.conf besides "sudo systemctl reload nginx". As soon as I reload nginx my old version was working like before. I went ahead and did the update to v.19.5.26194.7292 and had no problem loading my web portal.

+1

i have upgraded my non-functioning 19.5 thru all the stable releases and no dice, today I bit the bullet and upgraded to the 19.6 pre-release and its back working.

Eric Davis even looked at my web.config, and his updated version also didn't work for me. 

this is hopefully able to help someone like myself, I didn't have a functional screenconnect for almost a month.

It also now works on firefox and chrome, they must have fixed the mono/TLS issue, I am not running nginx.

Same here.   Thought i'd installed a beta release on accident.   Page loads with IP fine.   Error returned with hostname.   configured as per web documentation in order to be functional with a multi-NIC box.   I can't configure as one comment mentioned (+:80) because other NIC is listening for another service.   Checked relevant lines before and after upgrade (from backup) and all seems intact.   here are the relevant lines that I use.    Next step is to compare line-by-line for discrepancies.  Will e-mail the web.config files if needed.

Below domains and IPs have been replaced

<add key="WebServerAddressableUri" value=“http://help.example.com" />

<add key="WebServerListenUri" value=“http://198.51.100.241:80/" />

<add key="RelayAddressableUri" value=“relay://help.example.com:8041/“ />

<add key="RelayListenUri" value=“relay://198.51.100.241:8041/“ />

curl -v http://help.example.com
* Trying 198.51.100.241...
* TCP_NODELAY set
* Connected to help.example.com (198.51.100.241) port 80 (#0)
> GET / HTTP/1.1
> Host: help.example.com
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 400 Bad Request
< Content-Type: text/html; charset=utf-8
< Server: Mono-HTTPAPI/1.0
< Date: Thu, 26 Dec 2019 21:26:10 GMT
< Content-Length: 35
< Connection: close
<
* Closing connection 0

+1

Update:

System info:

CentOS Linux release 7.7.1908 (Core) 3.10.0-1062.9.1.el7.x86_64 #1 SMP. No nginx reverse proxy.

Xeon(R) E3-1270 v3 @ 3.50GHz w/32GB

netstat output when screenconnect running typically:

Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name

tcp 0 0 198.51.100.241:80 0.0.0.0:* LISTEN 29303/mono
tcp 0 0 198.51.100.157:80 0.0.0.0:* LISTEN 7677/httpd

As a test, stopped the service and restored old web.config in place of new web.config had same result. I agree that they could take a page out of Ubiquiti’s playbook. You’d think a release version would undergo testing of basic host headers. (i.e. real world scenarios) .  Had been working with a rep on expanding the services I have from Connectwise... may hold off a bit longer now.

Not foreseeing any timely response here, I tried out the debug release 19.6.26188.7290 before pulling the trigger on a restore

Truncated output from install:

.….Running 'Transform configuration files'...

mono: /lib64/libc.so.6: version `GLIBC_2.25' not found (required by mono)

mono: /lib64/libm.so.6: version `GLIBC_2.27' not found (required by mono)

mono: /lib64/libc.so.6: version `GLIBC_2.25' not found (required by mono)

mono: /lib64/libm.so.6: version `GLIBC_2.27' not found (required by mono)

mono: /lib64/libc.so.6: version `GLIBC_2.25' not found (required by mono)

mono: /lib64/libm.so.6: version `GLIBC_2.27' not found (required by mono)

mono: /lib64/libc.so.6: version `GLIBC_2.25' not found (required by mono)

mono: /lib64/libm.so.6: version `GLIBC_2.27' not found (required by mono)

Running 'Start screenconnect service'...


Installation complete!


Trying to figure out the best URL for you to use...


mono: /lib64/libc.so.6: version `GLIBC_2.25' not found (required by mono)

mono: /lib64/libm.so.6: version `GLIBC_2.27' not found (required by mono)

To access your new ScreenConnect installation, open a browser and navigate to:

(This space unintentionally left blank)


FAIL mode enabled.


Restored from backup version 19.4.25759, downloaded and reinstalled. Working fine again.

Will monitor this thread, as well as the changelog when a new release comes.

Same issue with the latest 19.5 release (19.5.26194.7292).  I also can't attempt the +:port modification because this is a multi-nic system and CC is configured to listen on an actual IP address (not localhost).  I also run an NGINX reverse proxy and have never had problems before (though it's been a while since I upgraded).  After rolling back to my 19.1 install everything works fine again.

This issue was reported a month ago.  How has this not been fixed yet?  I don't want really want to mess with the pre-release of 19.6 on my production system, and the only available pre-release is actually a couple days older than the latest 19.5 release anyway.  Even if the +:port modification actually does resolve the issue for some people that isn't a proper solution at all as it may break any server that actually runs anything other than CC.

I just tried v19.6.26314.7310 but got the invalid host error again so went back to v19.4 /I had performance issues with v19.5/. I'm using an nginx reverse proxy for https maybe that's the problem, but it’s working great with v19.4. I checked the config files but couldn’t find any changes in the access related lines. I really like screenconnect but since v19 I would say about 80 percent of the pushed out new versions gave me some kind of error so I had to revert back to a working backup.

When talking to support they stated Nginx will cause this issue. However I was not using Nginx and having the same issue. We ended up migrating to a Windows Server. As a temp fix we were able to edit the listening uri and replaced the IP address with a + symbol to get us back up and running after a tech pushed out updates to the clients as well.

I've only had bad advice from Support. So I would suggest Do NOT listen to them. Reason being is that I am running Ubuntu 18 LTS with Nginx as a reverse proxy. Plus I'm running the 19.5.26194.7292 version with currently no issues.

Did you try the configs that I added to this thread?


I notice no performance issues but I have a small set of unattended. 270 odd. Only 3 techs using SC.

If support is blaming it on NGINX that is pretty ridiculous.  It's obvious ConnectWise broke something since it works fine with NGINX until the 19.5.x releases.  Not to mention that using NGINX as a reverse proxy is a very common setup for all sorts of web applications.  So clearly ConnectWise has broken something fundamental to basic web protocols.  I just can't imagine it would be a hard fix since it's obviously been working fine for years.  I'll have to call in to complain since they don't seem to be actually reading these support threads anymore.  Yes, I'm venting a bit...  just please fix this simple issue!

Funny you should say that they never read this anymore. The support rep stated no one else was having this issue and that I was the only one reporting it. I referred him to this link. You would think a bug report forum would be something that they look at but there may be a disconnect between support and the devs.  

19.5 is working for me but after a couple of days every interaction with the admin page takes more and more time, I see the loading icon a lot while there is no load on the server. I also use an iPad Pro and it’s even worse there, most of the time I can’t even access the admin page with the app. No problems with 19.4 though

+1

TLDR: use the ip:port of WebServerListenUri as your NGINX proxy_set_header Host value

Ok, so I have spent the last couple hours playing around with a completely clean install on an Ubuntu host just to test things out. It looks like the root of the problem has to do with Mono bindings and expected header host values. It's probably related to the Mono upgrades in 19.5+. If Mono is bound to all interfaces (via http://+:port) then the request header host value oddly enough doesn't seem to matter (and thus is why people are putting that forth as a fix). But if Mono is bound to a specific IP then there seems to be a strict check for the host value, and in this case it only wants to accept a host value equivalent to the exact ip:port listed in the CC web.config WebServerListenUri parameter. All of this applies whether or not there is a reverse proxy configured not not. A simple test using curl without any reverse proxy set up will show that a request specifying a host other than the WebServerListenUri value will fail if CC is bound to a specific IP but will succeed if that value is used as the host header.

Given a WebServerListenUri parameter defined as:

<add key="WebServerListenUri" value="http://192.168.10.90:4000/" />

Failing Results (edited for privacy):

curl -v -H "Host: screenconnect.domain.com:4000" http://screenconnect.domain.com:4000

* Rebuilt URL to: http://screenconnect.domain.com:4000/

* Trying 192.168.10.90...

* TCP_NODELAY set

* Connected to screenconnect.domain.com (192.168.10.90) port 4000 (#0)

> GET / HTTP/1.1

> Host: screenconnect.domain.com

> User-Agent: curl/7.58.0

> Accept: */*

>

< HTTP/1.1 400 Bad Request

< Content-Type: text/html; charset=utf-8

< Server: Mono-HTTPAPI/1.0

< Date: Wed, 15 Jan 2020 03:55:38 GMT

< Content-Length: 35

< Connection: close

Successful Results:

curl -v -H "Host: 192.168.10.90:4000" http://screenconnect.domain.com:4000

* Rebuilt URL to: http://screenconnect.domain.com:4000/

* Trying 192.168.10.90...

* TCP_NODELAY set

* Connected to screenconnect.domain.com (192.168.10.90) port 4000 (#0)

> GET / HTTP/1.1

> Host: 192.168.10.90:4000

> User-Agent: curl/7.58.0

> Accept: */*

>

< HTTP/1.1 302 Found

< Server: ScreenConnect/19.5.26194.7292-3632157263

< Location: /SetupWizard.aspx

< Cache-Control: private

< Content-Type: text/html; charset=utf-8

< Date: Wed, 15 Jan 2020 04:02:27 GMT

< Content-Length: 132

< Keep-Alive: timeout=15,max=100

I haven't replicated my results yet on my production system, but it looks like the issue is resolved if I either remove the "proxy_set_header Host" directive entirely or manually set it to the internal ip:port of the CC server (WebServerListenUri). Since the proxy_pass value is already pointing to that internal ip:port there is no need to rewrite the host header of the proxy request as it will pass the proxy_pass value verbatim as the host header.

Oddly enough, this means that if you are hosting on Linux, need to bind to a specific IP, and aren't using a reverse proxy yet then I think it will be required to from now on. Unless ConnectWise migitates this behavior in a future release I don't see any other way to rewrite the host header to match the WebServerListenUri value. This is a bit ironic as the Mono upgrade was supposed to *solve* problems with Linux hosts.

I'll post again once I confirm it works on my production system (may not have time to do the upgrade until tomorrow).

so in looking at your instructions,the following did work for me after upgrade, thank you for sharing.

Removed the following from /etc/nginx/conf.d/ourdoman.conf file:
# proxy_set_header Host $host;

Added the one below, to reflect what was in the /opt/screenconnect/web.config, i.e. WebServerListenUri

proxy_set_header Host 127.0.0.1:1050;

kind of odd that we had to change nginx during this upgrade when all others worked flawlessly in the past.

removing the proxy_set_header Host $host; line helped for me to access the admin page but I wasn't able to connect to the hosts, there was a connection error

frufru,
not sure why you cannot access hosts, that was the only change I made after upgrade.

did the clients auto update to new version? I believe there is a setting AutoReinstallClient...something something
can be set to "true" and the clients (hosts) will update to new version.

I hope that helps

@frufru I'm not exactly following.  The NGINX reverse proxy only deals with the website.  The relay used by the client connections shouldn't (doesn't need to be) be proxied by NGINX.  I think I'd need to get more info on your overall setup to see what might be going on.  But I don't see how changing the NGINX settings would affect the host to client communication at all.  Can you clarify what you mean when you say you weren't able to connect to the "hosts"?

I still also haven't had the time to upgrade my production system yet.  I'll probably be doing that late tonight, and then I'll report back with results.

+1

I can confirm that I upgraded to the (now released) 19.6.26378.7317 and with the fix I detailed above everything is working fine (at least as far as the issues covered in this thread).  This includes connecting to access clients with no issues.  So I'm pretty confident in the required configuration I detailed for on-premise Linux installs needing to be bound to specific IP addresses.


I also tested it without the fix and still got the invalid host error, so the 19.6 "stable release" doesn't change anything from 19.5 regarding this problem (most likely due to the Mono upgrade in 19.5).  I'm holding off on doing a lot of access agent updates for now just in case something else blows up, but I've tested the web interface as well as connecting to several clients and things are working fine.

I'm happy to review configuration details if someone can't resolve the error with their Linux on-premise install.

I know it’s strange. screenconnect is running on Debian 8 server with Plesk, these are the current nginx directives:


location ^~ / {

proxy_pass http://127.0.0.1:8040/;

proxy_redirect off;

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_max_temp_file_size 0;

client_max_body_size 50m;

client_body_buffer_size 256k;

proxy_connect_timeout 180;

proxy_send_timeout 180;

proxy_read_timeout 90;

proxy_buffer_size 16k;

proxy_buffers 4 64k;

proxy_busy_buffers_size 128k;


if I remove the proxy_set_header host line I can access the admin page but when I try to connect to a host it waits for a while and then I receive a refused connection error /ip: 127.0.0.1:8041/ . the problem is there with both the old and new client versions.


also version and browser url check gives me an error, with 19.4 only the external accessibility check wasn’t working


after you removed "proxy_set_header" host line did you re-add the following?

"proxy_set_header Host 127.0.0.1:1050;"  // i understand your port may be different

then run a "nginx -t" // for testing

then restart nginx?

From what i read on your post, i did not see if you modified the proxy_set_header directive but rather removed it completely.

support had me add a line to the webconfig for the 8041 error.   

<add key="RelayAddressableUri" value="relay://YOURURLGOESHERE:8041/" />

This worked thanks robert1212...

yes, I removed it, first I tried the modified line but a result was the same

I'm having problems with SSL on port other than 443. I've been running ScreenConnect with SSL enabled on port 8040 for years on CentOS 6. Upgrading to 19.6 is no go because of problems with new mono so decided to spin new vm on Ubuntu 18.04.3 and start fresh. Everything works fine if not using SSL. As soon as I change WebServerListenUri to https I'm getting "PR_END_OF_FILE_ERROR" in Firefox and "ERR_CONNECTION_RESET" in Chrome. If I change WebServerListenUri port to 443 SSL works fine on both Firefox and Chrome. I'm not using any proxy, just plain 443.cer/443.pvk mono certs like been doing for years until version 19.5 came out


EDIT: I figured it out. It seems that new version of mono looks for .cer and .pvk files matching port number set WebServerListenUri so in my case files need to be named 8040.cer and 8040.pvk. Versions up to 19.4 were looking for 443.cer and 443.pvk no matter what port was set in WebServerListenUri

@frufru I think I would need to see the full nginx config and CC web.config to determine anything further.  There is no reason why an nginx instance proxying to port 8040 would interfere with communication to the relay running on port 8041.  There has to be something else going on that it causing the issue.  It's probable there is something else going wrong during the upgrade.  Are you getting any errors during the upgrade?  And, after the upgrade, if you don't change the proxy settings but log into the admin site using the IP directly (http://127.0.0.1:8040) can you connect to clients then?

I'm a bit worried reports of problems that likely are caused by something else are going to obscure the info in this thread.  It's probably better if we move the discussion somewhere else (or at least to another thread).

@frufru & Davison I'm in the same boat with not being able to access my host when modifying proxy_set_header Host $host; in anyway.

I would need to see the full web.config and full nginx config file, as well as the platform OS details and output of any errors during the screenconnect upgrade (if any) before I could make any determination as to what is going on.  Unfortunately these forums don't offer private messaging and don't facilitate longer discussions well.  If you have Github accounts maybe you and frufru could create gists with the content of your configuration and link them here?  It would be easier to discuss there as well.

i am seeing same behavior with connecting to hosts over 8041. centos7/nginx setup here.

great, the RelayAddressableUri line helped, thanks!  

I'm glad a couple of you that were having issues seem to have it sorted out.  It would still be helpful if we had a reference of the different configurations that are causing issues.  I can only guess that the logic CC is using to "infer" the relay configuration somehow fails when certain conditions are met (thus explaining why explicitly setting the RelayAddressableUri helps).


Another way to approach these problems may be to avoid using the loopback/localhost interface.  I'm wondering if binding to localhost is causing issues in this scenario, since my configuration is binding to actual IPs (not 127.0.0.1).


Also, it's worth reiterating that these Mono related issues only seem to appear if CC is bound to a specific IP.  If you don't actually need to bind to a specific IP due to other apps or services then the easiest solution is likely to just use the + wildcard in the WebServerListenUri as mentioned earlier in this thread since that seems to sidestep the Mono hostname problem.

today I experienced a server slowdown again with 19.6, I didn’t had the time to investigate so I just went back to 19.5 if the problem comes back then I still have a backup of a perfectly working 19.4 install.

by the way the linux versions of 19.6 are gone from the download page.

This might be the reason for the slowdown, I have hundreds of lines like these: