Navigraph’s website loads fine, icmp to SB is fine (<60ms and stable), name resolution is fine but the site fails to respond 90% of the time. This happens in browsers (google and edge) and in msfs as well (plans won’t load etc.) - It’s been like this for almost a month or so from Augusta, Georgia and Dallas, TX. This happens on initial load or trying to generate a route. It’s almost as if a cdn or load balancer is intentionally throttling inbound traffic.
1 Like
Hi,
Since most users have no issues (currently almost 1000 users using the website), I have to assume it’s something specific to your PC, network, or ISP. I don’t see any obvious cause in the website logs.
You seem to connect from many different IP addresses from different providers. Next time it does this, can you take note of your current IP address? Easiest way is to go to www.google.com and type “What is my IP” in the search.
I’d like to see if there’s a common thread between the IP addresses when this happens (for example, if it’s always happening on IPs from a certain provider, or if it happens regardless of the provider). Once you’ve done this for a week or so and have a few IP addresses, you can e-mail me or private message me the IPs if you prefer not to post them here.
Also, when it happens, if you try again immediately after does it sometimes work? Or does it always time out from that point on.
Best regards,
1 Like
Thank you for your response.
For background, I’m bonding 5 connections from the Psychz Data Center (Tier 4) in Dallas. Changing the IP might resolve it for a moment but then the problem comes back - stalling on the main request. Certain applications may use a different IP, MSFS, LNM, etc based on latency.
Headers, requests, ssl etc all download fine - it’s just he main request lags if I don’t use the site for a little bit - like the .php script is doing reverse lookup (which wouldn’t work or these IPs) or waiting on something else it can’t do.
Obviously, force-changing IPs isn’t a good solution as it disconnects my streams (msfs/twitch/yt etc) and they are a limited resource anyway. Ideally, if we want IP addresses, it might be easier to grep through web requests for my user id to find all relevant IP addresses in lieu of me “googling” for it as there would be no useful causative link between two separate requests and IP address. To clearify, packets are served on the host’s end on a first-come-first-served basis and I personally have no way of knowing which connection makes it to the SB site first.
That’s what I did initially, which is how I saw that you were using several IPs, but I can’t tell from my end which ones got through properly and which ones stalled. Or if I would even see the ones that stalled in the first place.
Neither SimBrief nor the .php scripts do reverse lookups before serving requests, as far as I know. But I can’t speak for the network, data center, and/or infrastructure between you and SimBrief’s server. Nowadays these data centers have a lot of protections in place (DDOS, etc), and who knows whether you might be tripping one of those. I don’t think I’d have any control over that anyways.
But with regards to the devtools picture you attached, I think the “Stalled” state is actually a browser issue. It happens even before the DNS lookup, i.e. the browser is waiting to send the request. Maybe it’s waiting for some requests to finish (I think Chrome has a maximum number of concurrent requests or something). Not sure if that’s related to your multiple/bonded connections you have.
Another thing to consider: the 2 browsers you mentioned trying (Chrome and Edge) are both Chromium based, so they both behave very similarly. Can you try with a non-Chromium browser, such as Firefox, and see if you get the same issue?
Best regards,