Failed to load resource: net::ERR_CONNECTION_RESET

I've finally solved the issue.

The breakthrough occured when I followed @john ktejik's directives:

https://stackoverflow.com/questions/4390134/failed-to-load-resource-under-chrome/26742627

I came to realize that the involved resource was encompassed within a .jar file. Therefore, I had to tell Apache2 to explicitely use "SetOutputFilter INFLATE;proxy-html;DEFLATE".

That's when I started to make some progress.

Since The inflate/deflate directive disables some links, I had to make it exclusive for javascript files:

"AddOutputFilterByType DEFLATE application/x-javascript".

Also, I needed an extra tweak which is to activate mod_expires and mod_headers (source).

Finally, I would rather clear cache before testing in different machines.

Clearly, the problem is related to Cache expiration and Static IP, which I can't really understand.

More importantly, the problem is solved (tested on different machines with different browsers with static and dynamic IP)!

I had similar problems when running a confluence instance (within a tomcat server) behind apache2 using either mod_jk or mod_proxy. When I tried to view the confluence wiki pages, I received following error messages:

Chrome: ERR_CONNECTION_RESET

Firefox: The connection was reset

The subtle problem was that some of the pages (like the login screen) could be viewed, while I lost the connection when viewing other pages. I also discovered that I can view all pages when I bypass the proxy (eg. issuing the request directly on the machine where tomcat/confluence was running using a SOCKS proxy over ssh).

Finally, I found out that the problem was caused by double compression performed by confluence and apache2. This caused that the content was compressed twice which cannot be handled by the client.

Apache2 was using mod_deflate to compress content sent from the server to to the client. I came across these instructions on testing for (and disabling) mod_deflate.

Turning-off compression in the confluence web application solved the problem for me, as described here.

In my case, the Apache instance is shared between a number of applications/developers and I guess an upgrade or reconfiguration of the sever which I was not aware of has introduced these issues.