Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

net::ERR_CONNECTION_FAILED error reported by Google PageSpeed Insight #12219

Closed
bldy9 opened this issue Mar 8, 2021 · 4 comments
Closed

net::ERR_CONNECTION_FAILED error reported by Google PageSpeed Insight #12219

bldy9 opened this issue Mar 8, 2021 · 4 comments

Comments

@bldy9
Copy link

bldy9 commented Mar 8, 2021

Several of of our servers started to experience the same issue where the online tool is unable to fetch the URL with the following error:
Lighthouse returned error: FAILED_DOCUMENT_REQUEST. Lighthouse failed to load the page you requested reliably. Make sure you test the correct URL and that the server responds correctly to all requests. (Details: net :: ERR_CONNECTION_FAILED)
Example:
https://developers.google.com/speed/pagespeed/insights/?hl=bg&url=https%3A%2F%2Fnossl.ukpro6.fcomet.com%2F
However, I am fully able to audit the page using the lighthouse addon in my browser and curl requests to the reported URL return 200 response code:

  • Trying 176.58.96.134...
  • TCP_NODELAY set
  • Connected to nossl.ukpro6.fcomet.com (176.58.96.134) port 443 (#0)
  • ALPN, offering h2
  • ALPN, offering http/1.1
  • successfully set certificate verify locations:
  • CAfile: /etc/ssl/certs/ca-certificates.crt
    CApath: /etc/ssl/certs
  • TLSv1.3 (OUT), TLS handshake, Client hello (1):
  • TLSv1.3 (IN), TLS handshake, Server hello (2):
  • TLSv1.2 (IN), TLS handshake, Certificate (11):
  • TLSv1.2 (IN), TLS handshake, Server key exchange (12):
  • TLSv1.2 (IN), TLS handshake, Server finished (14):
  • TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
  • TLSv1.2 (OUT), TLS change cipher, Client hello (1):
  • TLSv1.2 (OUT), TLS handshake, Finished (20):
  • TLSv1.2 (IN), TLS handshake, Finished (20):
  • SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
  • ALPN, server accepted to use http/1.1
  • Server certificate:
  • subject: CN=nossl.ukpro6.fcomet.com
  • start date: Feb 9 11:35:50 2021 GMT
  • expire date: May 10 11:35:50 2021 GMT
  • subjectAltName: host "nossl.ukpro6.fcomet.com" matched cert's "nossl.ukpro6.fcomet.com"
  • issuer: C=US; O=Let's Encrypt; CN=R3
  • SSL certificate verify ok.

HEAD / HTTP/1.1
Host: nossl.ukpro6.fcomet.com
User-Agent: curl/7.58.0
Accept: /

< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Date: Mon, 08 Mar 2021 15:16:24 GMT
Date: Mon, 08 Mar 2021 15:16:24 GMT
< Last-Modified: Mon, 18 Apr 2016 17:46:39 GMT
Last-Modified: Mon, 18 Apr 2016 17:46:39 GMT
< ETag: "1580d5-1f36-530c5f1531dc0"
ETag: "1580d5-1f36-530c5f1531dc0"
< Content-Length: 7990
Content-Length: 7990
< Content-Type: text/html
Content-Type: text/html
< X-Varnish: 919068
X-Varnish: 919068
< Age: 0
Age: 0
< X-Cache: MISS
X-Cache: MISS
< Accept-Ranges: bytes
Accept-Ranges: bytes
< Connection: keep-alive
Connection: keep-alive
<

  • Connection #0 to host nossl.ukpro6.fcomet.com left intact

We are using the Cachewall service as a reverse proxy for the Apache web server and the issue seems to be somehow related to that, as when the Cachewall is disabled the online tool is able to fetch the resource. However, we have performed no changes on the Cachewall configuration and the same has not been updated for months, while the issue started to occur just e couple of days ago.

Can we, please receive some assistance and insight, as no errors are generated on the server and the ERROR message provided by the tool does not give us any specific information on what exactly might be causing the issue, so we can troubleshoot it further, while everything is seemingly working as it should in the browser and via curl.

@devtools-bot
Copy link

Thanks! Appreciate you filing this bug. 👏

This is a known issue, most well described in #2784. So, we'll automatically close this as a duplicate.

However, if you believe your bug is different than the cases described there, please comment here with "necessarily-wide-alpaca" and I'll reopen this bug. 🤖 Beep beep boop.

@bldy9
Copy link
Author

bldy9 commented Mar 8, 2021

necessarily-wide-alpaca

@connorjclark
Copy link
Collaborator

related: #7326

Thanks for the report. We are investigating.

@connorjclark
Copy link
Collaborator

dupe #12222

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants