New Colocation center named NQN fails to connect


I have been using Cloudflare Warp client for over one year without issue from Argentina. The Coloaction centers usually show EZE and GRU. Recently I have been unable to connect using the Warp. Now I notice that the Colocation center has changed to NQN which is most likley Neuquén, Argentina. Is there something I can do to debug, or send you logs to help determine the problem?

When I switch from my ISP to my cell providers network, the colocation center changes to EZE and everything works fine. Same experience from all devices on my network. IOS, Android and Mac OSX 11.6.4

Thank you,

For WARP, always best to let the team know using the in app :wbug: button and sorry for the issues.

Can you do a traceroute to from the machine that gets routed to NQN?

Thanks for the reply. Yes I did report the issue using the app :wbug: button 24 hours ago. Now I thought to check here as well.

1 Like

Yes. Without Warp client running this is the results

traceroute to (, 64 hops max, 52 byte packets
 1  casarouter (  5.005 ms  1.146 ms  0.925 ms
 2 (  1.170 ms  1.112 ms  0.995 ms
 3 (  47.629 ms  65.875 ms  48.499 ms
 4 (  105.186 ms  62.710 ms  180.101 ms
 5 (  55.268 ms  135.040 ms  74.388 ms
 6 (  65.076 ms  206.199 ms  99.933 ms
 7 (  79.252 ms  89.574 ms  94.823 ms
1 Like

Are you routed to EZE now? Your route goes via Buenos Aires and EZE should be the closest data center. GRU is in São Paulo, Brazil and a non optimal route.
You might be rerouted by a Cloudflare server or your ISP might be rerouting you when there is a lot of traffic on their network. See
I could not find NQN in the Cloudflare servers list, but it is still in Brazil and closer than GRU.

I do not know if I am routed to to EZE. Tracert does seem to indicate that it is, right? Yes my local ISP WISP NAT network not optimal, and often does fail, though Warp has been unable to connect for the past two weeks. Plus this ISP customer support is very poor, so I am trying to gather as much information to approach them with questions. Client wireguard to my own self hosted WG at us-east-01 AWS, as well as Tailscale both work.

I assume NQN is very new which is why it is not yet on the Though I wonder if it not yet completely setup and still the Warp client is forcing that colocation center. I am less than 10km from there.

Hello dear,

I don’t know what your connection ISP is or through which Carrier you operate, but consider analyzing if they have an exchange agreement with Cabase IXP (peering):

Then, in these latitudes (I’m from Córdoba), we know that ISPs have a bad habit of using Proxy/NAT and other non-transparent things.

For example, never in years have I been able to get traffic from large sites where I worked to use routing to Córdoba (being from Córdoba) or Chile/Santiago, even closer geographically and by network would be Ezeiza or GRU; but it was all going to MIA. In some ISPs this is understandable due to the cost of traffic and IXP peering, in others it is bad configurations.

This may interest you, although it is old:

Footnote: Cloudflare’s POP’s servers in Argentina are within Cabase locations. But big ISPs (Fibertel, Telecom, Telefónica) filter, do not make agreements or restrict too much, BTW they end up routing via MIA or GRU for eficiency.

Thanks. I do see my ISP in that last of Cabase partners.

I never heard from Cloudflare support though perhaps they acted upon my data submissions and requests for help. Or some variable changed the colocation center today after 2+ weeks without connection. All my devices in my network were no longer being automatically set to use the NQN Colocation center. They were set to use the EZE center again, and everything was working fine for a few hours.

Later, the Warp client changed again to use NQN Colocation center. Now they are unable to connect to Cloudflare.

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