There is no way of suppressing it (other than disabling errors to console).
And 1 second is a ridiculously low timeout. IIRC the W3C specs recommend no less than a couple of minutes.
Now that you mentioned the timeout. I have read that a connection is kept alive for subsequent request but individual requests can timeout. So is the timeout for individual request or for the handshake?
I am actually communicating with a server hosted in the same machine for real time data so a few seconds late is already too much and would be discarded.
I find not being able to handle the error ourselves quite ridiculous. Imagine telling your boss you can do nothing about the error on a supposedly production ready project.
The timeout is for overall request - entire response is supposed to be received in this time. Connections are reused, but if you do more than one request at the same time, you get multiple connections and many simultaneous requests will cause new connections being opened, because connection cache only keeps certain number of connections.
The error is for information to help diagnose the problems. Granted, the intent is for nastier network failures, not timeouts. But if you are flooded with timeouts, it means either your timeout is too small, or server is underperforming, or the chosen solution is not the best (HTTP is far from being the most performant protocol).
Does curl or PostMan work? If so, compare the requests with Charles Proxy. If all requests are timing out even with a higher time out value, there is likely an issue with your server that you would need to address. Perhaps it is a local firewall or proxy issue.