Score:0

Server

HTTP request fails with connection time out, but only from our server

Agent Friday

2/1/24, 3:38 AM

My web application is running on a dedicated linux server located at a major hosting company. It needs to connect to an API provider, but libCurl always reports a connection timeout. I've boiled it down to the simplest test I can, which is to make a request with no payload via CLI curl. From our server, it always times out:

[linesk5@millenniumfalcon home]$ curl --connect-timeout 5 https://gateway.transit-pass.com/servlets/TransNox_API_Server
curl: (28) Connection timed out after 5001 milliseconds

The identical command issued from any other machine I've tested always gives a response:

[Steves-MBP:home $] curl --connect-timeout 5 https://gateway.transit-pass.com/servlets/TransNox_API_Server
<?xml version='1.0'?><InfoNox_Interface><Status><Code>911</Code><Message>Message not supported</Message></Status></InfoNox_Interface>

I've consulted support for our service provider, and they tell me that destination is not being blocked by our firewall. And so far support for the destination domain is telling me they do not see any connection attempts and they don't do any whitelisting or blacklisting.

Is it even feasible that something in between the two servers could be blocking the traffic? What tools or techniques might I use to troubleshoot this further? My gut says there must be something on their end that is causing connections from our server to be ignored, but I don't don't have any evidence to provide them to back it up.

I ran traceroute on both the server and my local machine, and the nature of the output didn't seem to differ in any significant way...

Last few hops from my server:

3  * * *
4  * * *
5  * * *
6  * TOTAL-SYSTEM-SERVICES-LLC.customer.alter.net (152.179.178.254)  10.354 ms *
7  * * *
8  * 12.122.108.125 (12.122.108.125)  11.750 ms  11.827 ms
9  * 12.116.151.54 (12.116.151.54)  11.629 ms  11.634 ms
10  * * * // repeats forever

Last few hops from my workstation:

9  sea-b3-link.ip.twelve99.net (62.115.139.133)  7.258 ms  7.738 ms  7.764 ms
10  * * *
11  verizon-ic-356975-sea-b2.ip.twelve99-cust.net (213.248.94.149)  9.323 ms  8.616 ms  9.736 ms
12  * * *
13  * * *
14  0.ae1.gw3.phx2.alter.net (140.222.227.251)  42.390 ms
   0.ae2.gw3.phx2.alter.net (140.222.227.253)  39.289 ms  39.829 ms
15  total-system-services-llc.customer.alter.net (152.179.178.254)  43.472 ms  41.972 ms  40.418 ms
16  * * * // repeats forever

225

0 + 9

linux

https

timeout

connection

curl

Jaromanda X

2/1/24, 6:15 AM

run a traceroute to `gateway.transit-pass.com` from both servers to see where the blockage is

Agent Friday

2/1/24, 6:19 AM

How would I recognize a blockage? The output on both systems never ends and consists mostly of * * *

Jaromanda X

2/1/24, 6:28 AM

right, but is the last valid hop the same for both?

Agent Friday

2/1/24, 6:54 AM

Not even close. Pasted the last hops for each above.

Jaromanda X

2/1/24, 7:24 AM

`152.179.178.254` seems to be the last hop on your workstation, and it seems on the server it's an intermediate hop ... which one works? workstation or server?

Agent Friday

2/1/24, 7:36 PM

Wow, how did I miss that? The workstation works, server does not.

Jaromanda X

2/1/24, 9:10 PM

by the way, the fact that you end up with `* * *` after a particular hop is not an issue. When I traceroute to your server from one location, the last hop displayed is `152.179.178.254` - from another location, the last hop displayed is `12.116.151.54` - just like your results - except the second traceroute doesn't have `152.179.178.254` as an intermediate hop like in your case - so, that's all a bit odd

Jaromanda X

2/1/24, 9:26 PM

also, according to one geoip site, `12.116.151.54` and your server are at the same co-ordinates - in the middle of a reservoir :p so, chances are that should be the last hop - however routing is not always that simple

Agent Friday

2/1/24, 10:06 PM

The alter.net IP (common node between both routes) is owned by Verisign. This leads me to speculate about possible blacklisting... The two nodes after that are with AT&T (according to whois)

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: HTTP request fails with connection time out, but only from our server

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.