Failed to load resource: net::ERR_CONNECTION_RESET

Question

Since I started using an application behind a reverse proxy (Apache2's mod_jk), I've noticed some pages won't load (They would without the reverse proxy settings).

It was a subtle error which I had to inspect to find it out, thanks to Google Chrome: Failed to load resource: net::ERR_CONNECTION_RESET.

Simply, a JavaScript file would partially be loaded (~12KB loaded out of ~50KB).

I thought something was wrong with Apache2, mod_jk, AJP, or Jetty.

But then I engaged into an investigation where I would use different browsers along with different networks.

Verdict: This error (ERR_CONNECTION_RESET) occurs only when I use networks with static IP.

I decreased security level in one router but in vain.

Are networks with static IP equipped with higher levels of security?

How to overcome this issue?

This is a stalemate because the reverse proxy is mainly destined to take advantage of static IP addresses of our selling points for an increased level of security.

Solution 1

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)!

Solution 2

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.

Solution 3

Faced similar problem (Chrome: ERR_CONNECTION_RESET) when accessing rstudio server hosted in CENTOS and tried to access http://:8787 from Windows 10 desktop; After successful login into R-StudioServer, browser landed in blank page; Upon verification through (using F12 in chrome browser) its found that

7FB4E8E294D00886385447916050EC79.cache.js Failed to load resource: net::ERR_CONNECTION_RESET

After several trial and error attempts like upgrading R/Chrome browser/ disable cache; I finally found that site was blocked by antivirus program (Trend Micro Maximum security -> in my case); Later I added to trusted sites to proceed further

Comments

[Profet]

I had the same problem which was solved after enabling mod_expires in my Apache config. However, I don't know why it suddenly stopped working, despite working flawlessly for years without the mod enabled.