API Endpoint pass-through timing out (2nd draft)

I have a DNS A Record for trace.filevacuum.com to go to my server’s IP.

This works for a Go Server running at:
http://trace.filevacuum.com:16686 (you won’t see this page as it’s just for my IP)

However, when opentelemetry-rust tried to POST to http://trace.filevacuum.com:14268/api/traces it times out. When POSTing to http://trace.filevacuum.com:14268/api/traces on POSTMAN it times out:

POST http://trace.filevacuum.com:14268/api/traces
Error: connect ETIMEDOUT 555.555.555.555:14268
Request Headers
User-Agent: PostmanRuntime/7.26.10
Accept: */*
Cache-Control: no-cache
Postman-Token: <TOKEN>
Host: trace.filevacuum.com:14268
Accept-Encoding: gzip, deflate, br
Connection: keep-alive

(at least I can see in PostMan that it hit my server’s IP and port)


  • I turned off the Cloudflare proxy (just DNS) to try and help less things get in the way of the POST passing through.
  • I’ve turned off as many security options as I could and tried other configurations.
  • I set a specific Firewall Rule to Allow my IP.
  • I set a Rule to allow this URI Path /api/traces:

I know the endpoint works because when I make it public opentelemetry-rust POSTs traces to it fine that show up in the Jaeger app.

Here’s my Cloudflare DNS:


My Vultr Server’s Firewall Settings:

I thought setting the DNS A Record for trace.filevacuum.com to just DNS and off proxy would have done the trick but it’s still getting caught somewhere in Cloudflare and timing out.

Getting a POST to pass through shouldn’t be too hard to do right?
Once I get it passing through I’ll setup mTLS via APISheild but need to get past this first.

Unless it’d listen to API Rules and let it through that way? :man_shrugging:t2:

Any help is greatly appreciated. :bowing_man:t2:‍♂

You are using ports that are not supported by Cloudflare. Check the documentation here:

1 Like

If it’s DNS-Only, then Cloudflare can’t be interfering with the connection to that hostname.

However, in your Vultr firewall, you’re only allowing connections to 14268 to come through Cloudflare, but that only applies to :orange: Proxied hostnames…which that hostname isn’t. So connections to 14268 aren’t going to come through the “Cloudflare” source in the Vultr firewall.

1 Like

This is good to know :memo:

but no one would be able to use CF is it only supported those handful of ports. Much software uses specific ports that can’t be changed that run on CF just fine.

I tried it as proxied originally with no luck. Maybe I need to give it more time to propagate before giving up on it. Trying again now…

However you see form my POSTMAN mention that the POST was finding my server’s IP, and now as a proxied A Record, I can’t even reach the Jaeger Go web server at http://trace.filevacuum.com:16686 anymore. :slightly_frowning_face:

Cloudflare is primarily a web proxy, using ports 80 and 443. The additional ports listed above are mainly those used by common hosting tools like cPanel.

Additional ports are available
Using products like Cloudflare Spectrum, or Magic Transit.

2 Likes

Learning more! Thanks, Michael :bowing_man:

All other TCP/UDP protocols ENTERPRISE

Ouch :face_with_head_bandage:

@michael do you know if the supported ports can do UDP connections?

Without Spectrum, the connection is terminated on Cloudflares infrastructure, and the supported ports are used for HTTP or HTTPS. UDP is probably allowed in the limited context required for HTTP/3 (QUIC), but I don’t know if that would be enabled on the non-standard ports.

I suspect you are thinking of running your application on the standard Cloudflare ports, and then running non-HTTP protocols through them. That probably will not work unless the protocol you are running is HTTP, or is tunnelled over HTTP.

1 Like

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.