--- title: "Developer Network Self-Check (2026): Exit IP to AI API Latency" description: "A nine-point developer network self-check: exit IP, split routing, DNS, WebRTC, IPv6, AI API latency, CDNs and status feeds, with CLI checks and cdnping tools." url: https://cdnping.org/en/blog/developer-network-self-check-2026 language: en published: 2026-10-17 category: "Troubleshooting" tags: ["network self-check","developer network","AI API","network troubleshooting","checklist"] source: cdnping.org license: Free to quote and summarize with a link to the url above. --- # Developer Network Self-Check (2026): Exit IP to AI API Latency A developer's network self-check comes down to nine items, checked in this order: exit, resolution, browser, protocol stack, target service, frontend assets, subscriptions. The first six show up on one page, cdnping's [IP and environment check](/en/ip). AI API reachability and latency are measured with the [online speed test on the home page](/en). Below is a printable checklist first, then notes on how to judge each item and where to look first when something is wrong. ## One-page checklist Run it through once in each of three situations: you changed networks (new office, a business trip, a new router), you changed proxy or split-routing rules, or an AI tool suddenly got slow or started throwing errors. | # | Check | Expected result (fill in for your setup) | Tool | Done | | --- | ---------------------- | -------------------------------------------------------------- | -------------------------------------------------------- | ---- | | 1 | Exit IP and ownership | Exit region and IP type match your configuration | [/en/ip](/en/ip) exit IP intelligence | ☐ | | 2 | Mainland China split routing | Domestic sites go direct, overseas sites use the intended exit | [/en/ip](/en/ip) mainland split-routing check | ☐ | | 3 | Multi-exit consistency | Different targets see the same exit | [/en/ip](/en/ip) multi-exit check | ☐ | | 4 | DNS | Resolvers match the exit, no unexpected leaks | [/en/ip](/en/ip) DNS leak | ☐ | | 5 | WebRTC | No unexpected local or public addresses exposed | [/en/ip](/en/ip) WebRTC leak | ☐ | | 6 | IPv4 / IPv6 | The exit on both protocol stacks is as expected | [/en/ip](/en/ip) + `curl -4/-6` | ☐ | | 7 | AI API reachability and latency | Your usual APIs all connect; first connection and round trip are acceptable | [/en](/en) online speed test | ☐ | | 8 | Public frontend CDNs | The CDNs your project depends on load reliably | [/en](/en) speed test, [/en/benchmark/cdn](/en/benchmark/cdn) | ☐ | | 9 | Service status subscriptions | When something breaks, you can first rule out "the other side is down" | [/en/status](/en/status), [/en/down](/en/down), [/en/reports](/en/reports) | ☐ | The "Expected result" column is yours to fill in. The right answer differs between full-proxy, split-routing and direct setups. The point of a self-check is to confirm that actual behavior matches what you think it is, not to chase one fixed result. ## Do your exit IP and routing match expectations? ### 1. Reading the exit IP intelligence Open [/en/ip](/en/ip) and start with the exit IP intelligence. cdnping votes across 11 geolocation databases to place the IP and reports a confidence level. Low confidence means the databases disagree about who owns that network block, which is useful information in itself. Four fields matter most: - Native or broadcast IP: whether the block's registration location matches where it is actually used. The difference is explained in [Native IP vs. broadcast IP](/en/learn/native-ip-vs-broadcast-ip). - IP type: datacenter, residential, mobile or Tor. - Reputation score: aggregated from 14 reputation sources, including ip-api, proxycheck, IP2Location, StopForumSpam, the Tor exit list, hosting-ASN lists, and DNS blocklists such as DroneBL and SpamCop. The weight of every hit is published, so you can see which source flagged the IP instead of relying on the total alone. - Network registration: looked up through RDAP, showing the organization that holds the block. ### 2. Is mainland China split routing working? The mainland split-routing check on the same page reads the client IP and latency reported back by domestic Chinese CDNs (NetEase, Tencent, Douyin, Weibo, Youku, Xiaohongshu and others) and returns one of three verdicts: split routing, global proxy, or direct domestic connection. If you configured split routing but the result says "global proxy", there are usually two causes: the rules do not match domestic domains, or DNS is going through an overseas resolver and returning overseas CDN nodes. How split routing works and common setups are covered in [Split tunneling](/en/learn/split-tunneling). ### 3. Do different sites see the same exit? The multi-exit check reads the Cloudflare trace from sites such as Claude, ChatGPT and Grok, to see whether each target sees the same exit as you reach them. If your split rules are fairly granular, this is often where you find a domain taking a different route. The "latency profile" item next to it compares the round-trip time measured in the browser with the exit's TCP round trip measured by Cloudflare. A large gap usually means there is another relay hop in between. ## Are DNS, WebRTC and IPv6 leaking? ### 4. Where is your DNS resolver? The DNS leak check looks at which recursive resolvers the browser actually ended up using, and whether their location matches your exit. A resolver that is not near the exit has two practical effects: you get CDN nodes far from the exit, so access is slower, and the resolution requests reveal which domains you visit. The mechanics are in [DNS leaks and WebRTC leaks](/en/learn/dns-leak-webrtc-leak). From the command line you can do a rough check of the system's default resolver: ```bash # Show the resolvers the system uses cat /etc/resolv.conf # Linux scutil --dns | head -20 # macOS # Compare the system resolver with a specific resolver nslookup api.openai.com nslookup api.openai.com 1.1.1.1 ``` If the two answers fall in very different IP ranges, the system resolver is returning nodes from another region. Go back to the /en/ip page and look at the specific resolvers listed by the DNS leak check. ### 5. Which addresses does WebRTC expose? WebRTC powers audio, video and peer-to-peer connections in the browser. It gathers the machine's candidate addresses through STUN, and that process may bypass the browser's proxy settings. The /en/ip page lists the addresses WebRTC obtains. The test is whether every public address in the list is an exit you expect. If an address assigned by your ISP appears and you do not want web pages to see it, restrict WebRTC address exposure in the browser settings or with an extension. ### 6. Do IPv4 and IPv6 take the same path? On a dual-stack network, a proxy that only handles IPv4 while IPv6 still goes direct is a common reason for "the proxy works sometimes and not other times". /en/ip shows the IPv4 and IPv6 exits separately, and from the command line you can compare them like this: ```bash curl -4 -s https://www.cloudflare.com/cdn-cgi/trace | grep -E '^(ip|loc|colo)=' curl -6 -s https://www.cloudflare.com/cdn-cgi/trace | grep -E '^(ip|loc|colo)=' ``` If `loc` differs between the two outputs, the two stacks take different paths. There are two fixes: make the proxy client handle IPv6 as well, or turn off IPv6 on the machine. Choose based on your environment. ### What the browser environment check looks at The /en/ip page also checks time zone, language, fonts, hardware fingerprint, automation traces, and a browser engine version inferred from 23 features. Use these when you are asking why a web page thinks you are in a different region. Fingerprints are computed locally and not uploaded. ### Saving the results After the checks finish, the /en/ip page can generate a watermarked result image to attach to a ticket, send to a colleague, or keep for before-and-after comparison when you change networks. You can hide the IP address before generating it, so posting it in a group chat or a public issue does not expose your exit address. Save one image after each configuration change, and you will have a baseline to compare against the next time something breaks. ## AI API unreachable or slow: how do you narrow it down? ### 7. Use the online speed test for first connection and round trip Open the online speed test on the [cdnping home page](/en). The browser sends requests to 15 AI model APIs: OpenAI, Claude, Gemini, xAI, Mistral, Groq, OpenRouter, DeepSeek, Zhipu, Kimi (Moonshot AI), Alibaba Cloud Model Studio, Volcengine Ark, SiliconFlow, AGI Plan and cdnping itself. Each target gets two numbers: - First connection: includes DNS resolution and the TLS handshake, reflecting cold-start overhead. - Round trip: the median of 3 requests over a reused connection, closer to the network cost of each request during sustained work. High first connection with a normal round trip usually means the DNS or handshake stage is slow. If both are high, the problem is more likely the route itself. For how latency adds up when reaching AI APIs from mainland China, see [AI API latency from China](/en/learn/ai-api-latency-china). Speed test results can be counted anonymously in the statistics, and no IP is recorded. You can also break down per-stage timings from the command line: ```bash curl -o /dev/null -s -w \ 'dns=%{time_namelookup}s tcp=%{time_connect}s tls=%{time_appconnect}s total=%{time_total}s\n' \ https://api.anthropic.com/ ``` Only the connection stages matter here, so a 401 or 404 response does not affect the conclusion. ### Is it your network or their service? The browser speed test reflects the whole path from you to the target. To rule out a problem on the provider's side, check the [API status page](/en/status). It probes each official API endpoint from the Cloudflare edge every 5 minutes, without going through your local network. As an example: from 08:40 to 10:05 UTC on October 17, 2026, cdnping probed from the Cloudflare Denver (DEN) edge node. The median latency was 73 ms for the Claude API, 96 ms for the OpenAI API and 353 ms for the DeepSeek API. In the same window the Kimi open platform had 94.4% availability, and the other 14 targets were all at 100%. That window is only about an hour and a half, and the probe is in the United States, so it does not represent the latency you would measure from mainland China. It only tells you whether the service itself was healthy at the time. cdnping started collecting on 2026-10-17, so the sample is still small. The order to follow: 1. If a local speed test to an API fails, first check whether the matching entry on [/en/status](/en/status) is also abnormal. 2. Edge probe is fine but local is unreachable: go back to the earlier sections and check exit, routing and DNS. 3. Edge probe is also abnormal: go to [/en/down](/en/down) for user reports and synced official status pages for that service. It is most likely the provider's problem, so wait for recovery or switch to a backup service. If you call models through an aggregation gateway, the gateway is another hop. Take AGI Plan as an example (AGI Plan is a commercial partner of cdnping): [/en/status/agiplan](/en/status/agiplan) shows its edge probe results, plus an availability mirror calculated from real requests. Some AI services restrict use by region. The self-check is only for confirming that network behavior matches your expectations. Follow each service's terms of use and local laws and regulations when using them. ## How do you keep tracking frontend CDNs and service status? ### 8. Do public frontend CDNs load reliably? The home page speed test also covers 9 public frontend CDNs, and the [CDN speed ranking](/en/benchmark/cdn) summarizes anonymous test results. If your project depends on a particular CDN, test it from the networks your target users are on. For how to choose, see [Choosing a public CDN for China](/en/learn/choose-public-cdn-china). ### 9. Which status feeds to subscribe to A self-check answers "is my side correct?", while status subscriptions answer "is the other side having an incident?". According to the official status page records synced by cdnping, between 2026-09-17 and 2026-10-17 OpenAI had 25 incidents (4 major, 19 minor), Claude had 8 (6 major), and GitHub had 16 (5 critical). Confirming the other side's status first can save you a lot of detours when troubleshooting. Places you can subscribe: - [Weekly stability report](/en/reports): generated automatically every Monday, with subscription. - [Site updates](/en/changes): monitors 11 official changelogs, pricing pages and news pages, with RSS so you can drop it into a reader. - [Model watch](/en/models): built on OpenRouter's public API, showing each model's availability, latency and quantization changes across inference providers. - Open data `/api/status` (CC BY 4.0): plug it into your own monitoring or bots. For how the data is defined, see [Methodology](/en/methodology). ## Four things you can do right now 1. Print the checklist above or copy it into your team wiki, and fill in the "Expected result" column with your network configuration. 2. Run the check on [/en/ip](/en/ip), hide the IP, and archive the generated result image as a baseline for the current setup. 3. Run the AI API speed test on the [home page](/en) and note the first-connection and round-trip numbers for the two or three APIs you use most. 4. Add the [/en/reports](/en/reports) weekly report and the [/en/changes](/en/changes) RSS feed to your subscriptions, so next time something breaks you check status first and your own setup second.