Since yesterday we are seeing randomly error with the gmail API :
Failed to open TCP connection to www.googleapis.com:443 (Network is unreachable - connect(2) for [2a00:1450:400b:c03::5f]:443)
It suddenly started at 10:24AM yesterday. Last week we've already experienced something like this for 24h and it has disappeared without any changes on our side.
We are hosted on Heroku, I'm currently thinking of a DNS change, ipv4/v6 issues or something like this.
Related
Hosting a rails web app on heroku; no recent code changes but about 2 days ago the application started reporting constant H31 misdirect errors. After looking into the documentation, since the application was still accessible I moved on.
The next day users from some of the subdomains could not access the application while others could. The application uses a wildcard certificate and we are behind a WAF. The first thing I tried was checking firewall logs and nothing was showing as blocked. I turned off the firewall and connected the domain directly to the application and still received the H31 stream, after 15 minutes of no change i re-enabled the firewall.
Reached out to the firewall and they said that their logs only showed upstream prematurely closed connection while reading response header
At this point they suggested the issue was most likely on the Heroku DNS servers, so I'm waiting for a response at this point.
Is there anything I can do in the heroku environment that would change this or am I stuck waiting for a response?
Im running a Laravel 6 app on AWC EC-2 instance and have it configured to send mail via Gmail SMTP. Has worked perfect for nearly 2 years. Approx 1-1.5 days ago, the email function started throwing the Connection timed out error.
I tried switching ports, and changing TLS to SSL and no change.
Ive read dozens of threads with the same problem - but no help. Most suggest changing from driver smtp to sendmail - but that breaks all my email-send code.
I tried to telnet smtp.gmail.com 587 from the command line - and get Host is unreachable. There has been NO change to the code, config or setup recently.
My thoughts right now, are either:
AWS have blocked my smtp port,
Google has blocked my IP from sending mail,
My server MAY have reached a limit of some sort (but thought it will un-suspend in 24hrs if the case)
I am not sure HOW or WHERE to find that answer, or if there is another possible problem/solution here. I only have Basic support with AWS - so cant raise a standard tech support q.
Any suggestions would be greatly appreciated.
With thanks - James (Image of error and env below).
I'm using Google's simplehttp2server go-lang program to run some tests and have encountered a recurring error. Upon executing the TLS handshake I receive the following error:
2019/12/12 12:42:55 http: TLS handshake error from 127.0.0.1:36202: read tcp 127.0.0.1:5000->127.0.0.1:36202: use of closed network connection
I have updated my go version to 1.13.5 from 1.12.9 and tried two browsers (brave + chrome) plus curl and receive the same error code each time. It happens over HTTP/2 and HTTP/1.1. I have seem other answers from across the web but am still running into this error (ex1, ex2, ex3, ex4).
Very much appreciate any feedback, advice, or admonishment. Anything to help the migraine this problem is giving me!
edit: screenshot from my curl and running of simplehttp2server
example image from curl and simplehttp2server
This error happens when you have two websockets connected to a singular address using the same port from the same machine. One of the websockets will be able to connect fine but the other wont be able to make the connection.
I was making the same mistake and when I removed the duplicate connection the error resolved.
I tried to connect to the Push API in poloniex using python and followed the instructions on the answer here:
How to connect to poloniex.com websocket api using a python library
However I keep getting this error:
2017-06-25T04:07:04 dropping connection to peer tcp:104.20.13.48:443 with abort=True: WebSocket opening handshake timeout (peer did not finish the opening handshake in time)
Anyone know what's going on here? I can't figure it out from online documentation. Thanks!
As per #Cyphrags suggestion, I was able to get my autobahn websocket to work outside of localhost by increasing openHandshakeTimeout with factory.setProtocolOptions
factory.protocol = MyClientProtocol
factory.setProtocolOptions(failByDrop=False, openHandshakeTimeout=90, closeHandshakeTimeout=5)
Solution found via https://github.com/crossbario/crossbar/issues/930. Perhaps the reason it is needed has something to do with slow DNS routing taking longer than the default handshake time.
My app was rejected today due to 'not supporting IPv6'. I've attached screenshots of the error they received which comes from a Parse.com API call.
I could really use some help on this, as I have no clue where to start with this.
Does anyone know if Parse.com supports IPv6? Or do I need to add something to my code? Do I need to migrate to Parse Server?
Please help =\
---- EDIT ---- 9/22/16
OK so, after my first rejection due to "IPv6" issues, I re-submitted and the app was approved. I'd still like to understand if Parse.com and Parse Server are officially IPv6 compatible but as for now, I'm just happy my app was approved. I'll keep this thread open and will edit it when I find the answer.
I have a parse server hosted on Heroku which doesn't support IPv6 yet (see here). But your server is not the reason why the app is rejected. It is your app which should support IPv6.
A possible solution is to download the latest Parse framework from https://github.com/ParsePlatform/Parse-SDK-iOS-OSX/releases/tag/1.14.2 and replace the old ones. I think it should work.
Below is my comparison with the logs in the console for my app with the two different versions of Parse framework.
I have used Parse.framework and Bolts.framework from Feb 2016 in my Apple TV app and also just got rejected also for not supporting IPv6. I checked the log and found that
nw_resolver_start_crazy_eyeballs_timer Received IPv4 result first, performing crazy eyeballs: waiting 50ms on IPv6 for myapp.herokuapp.com:0.
__nw_resolver_start_crazy_eyeballs_timer_block_invoke Crazy eyeballs timer fired: did not receive IPv6 in time, reporting only IPv4 result for myapp.herokuapp.com:0
nw_resolver_cancel_crazy_eyeballs_timer Cancelling crazy eyeballs timer for myapp.herokuapp.com".
It seems the performance issue comes from the 50ms when the app loads.
I use the latest Parse framework and no "crazy_eyeballs_timer" shows up. The log seems more promising because I can see a IPv6 address in the log now.
nw_resolver_create_dns_service_on_queue Starting host resolution myapp.herokuapp.com:0, flags 0x4000d000
nw_resolver_host_resolve_callback flags=0x3 ifindex=0 error=NoSuchRecord(-65554) hostname=myapp.herokuapp.com. addr=0.0.0.0:0 ttl=60
nw_resolver_host_resolve_callback flags=0x2 ifindex=0 error=NoError(0) hostname=us-east-1-a.route.herokuapp.com. addr=88:ffff::bbbb:afb9.0 ttl=74
Here I changed the addr of my server in the log for security reason.
I will send a new update of my app to review and I believe that it should work. I will leave a comment when it gets accepted :)