Often the explanation is boring: the "what's my IP" page and the AI service never saw the same connection. An IP check only reports the public exit used to reach that site, over that address family, through whatever rule matched that hostname. An AI service on a different hostname can take a different path.

This post covers the three usual causes (dual-stack, domain-based proxy rules, terminal vs. browser), how to ask the service side which IP it sees, and the curl commands I use. At the end I mention a small tool I built for this, IP for AI, but you can do everything here with curl alone.

Cause 1: IPv4 and IPv6 are two different exits

On a dual-stack network your machine has two public identities. They can sit on different ASNs, show up as different regions, or one can go through a proxy while the other goes direct. A common setup: the proxy covers IPv4, and IPv6 quietly bypasses it.

Which family a given request uses isn't fixed. DNS can return both A and AAAA records, the OS sorts the candidates (RFC 6724 default address selection), and the client races connection attempts (RFC 8305, Happy Eyeballs v2). The page, the sign-in redirect and static assets can sit on different hostnames, so one session can even mix families. Seeing IPv4 on one site tells you nothing about what a different hostname got a second later.

One TCP connection has exactly one source address, so any single check sees one family. Force each family on purpose:

curl -4 -sS https://ipforai.cc/json
curl -6 -sS https://ipforai.cc/json

If both come back with the same country and network type, good. If IPv4 says one region and IPv6 says another, you've found a variable worth testing.

Cause 2: domain-based proxy rules

Rule-based clients (Clash/Mihomo and similar) choose a route per hostname. That's the point of split routing, and it also means "my IP" depends on which domain you ask.

Things that typically go wrong:

• The rule set covers chatgpt.com but not some other hostname the app actually requests.
• DOMAIN-SUFFIX and DOMAIN-KEYWORD behave differently. Suffix matches a domain and its subdomains. Keyword checks for a substring in the hostname, not the URL path.
• Rule order: an earlier broad rule catches the request before your AI rule does.
• DNS caching, or a client that doesn't cover every app, makes results look inconsistent between runs.

The opposite case also happens: every AI domain resolves to the same exit, and people assume split routing is "off" when it's working exactly as configured. A shared exit isn't automatically a bug. Compare against your rules, not against a guess.

Cause 3: your terminal is not your browser

curl in a terminal follows the HTTPS_PROXY / https_proxy environment variables and your OS routing. Your browser may use a system proxy, an extension, or something else. A VPS has no browser at all. If you test in one place and the failure happens in the other, you've compared two different paths.

Ask the other side: the cdn-cgi/trace endpoint

A local check can't tell you what a remote service saw. The useful trick is that sites served through Cloudflare expose a plain-text diagnostic endpoint at /cdn-cgi/trace. Several AI front-ends are on Cloudflare, so you can ask their edge which IP your request arrived from:

curl -s https://chatgpt.com/cdn-cgi/trace

The output is key=value lines. Trimmed, it looks like this:

h=chatgpt.com
ip=<your public exit as seen by this hostname>
loc=JP
http=http/2
tls=TLSv1.3
warp=off

ip is the source address of that connection and loc is the country Cloudflare assigns to it. Because the request went to chatgpt.com, it went through whatever proxy rule matches chatgpt.com. That's the point.

Run it per hostname and per family:

for host in chatgpt.com claude.ai grok.com; do
  for fam in -4 -6; do
    printf '%-12s %s  ' "$host" "$fam"
    curl $fam -s -m 8 "https://$host/cdn-cgi/trace" \
      | grep -E '^(ip|loc)=' | tr '\n' ' '
    echo
  done
done

Then compare with the exit a neutral site sees for the same family:

curl -4 -sS https://ipforai.cc/json | jq -r '.ipv4.ip // .ipv6.ip'
curl -6 -sS https://ipforai.cc/json | jq -r '.ipv6.ip // .ipv4.ip'

(/json fills only the family the server saw the request arrive on, so the other field is null. -4 controls how your machine connects. If there's another relay layer in front of you, the server can still record the other family, so print whichever field is filled.)

If chatgpt.com over IPv4 shows a different IP or country than the neutral check over IPv4, that hostname is taking a different path. Sometimes that's intended, sometimes it's a rule that doesn't do what you think.

Limits of this trick

• It only works on hostnames served through Cloudflare. If a service isn't, there's no /cdn-cgi/trace and you get no echo. Don't read an exit into a missing answer.
• It shows the exit for that hostname. An app's API, auth and asset hosts may route differently. The trace on a front-end domain is evidence, not proof of what every request in a session used.
• A matching exit doesn't mean your account, subscription or region is fine. It removes one network variable. That's all.

A debugging loop that actually attributes the cause

1. Record both exits separately: IP, country, ASN, and whether it looks like data-center or residential.
2. Record the service-side exits from the trace endpoints for the services you care about.
3. Check whether failures follow one address family or one hostname.
4. Change one thing, retest, and record again. Proxy covering IPv6, a single rule, one DNS setting. Change three things at once and you won't know which fix worked.
5. A short IPv4-only or IPv6-only test is a fine diagnostic. Don't leave it as your permanent setup; fix the proxy coverage or routing instead.
6. If the exits are aligned and stable and the service still fails, stop blaming the network. Look at the browser session, the exact error message, and the provider's status page.

The tool I built for this

After running those loops by hand too many times, I put them into ipforai.cc. It's free and needs no account. What it does today:

• Profiles your current IPv4 and IPv6 exits separately: region, ASN, network type (data-center / residential evidence), routing hints, and proxy / VPN / Tor and risk-list signals where data exists.
• Computes a 0–100 network environment score with itemized evidence. It's a reference for the network only, not any platform's official score, and not a ban predictor.
• An AI routing exit page that compares the exits supported AI endpoints echo back against the site's own exit.
• DNS-exit and WebRTC comparisons in the browser, plus symptom-first guides such as IPv4/IPv6 exit mismatch.

For servers there's a read-only POSIX sh script: it needs only curl, writes no config, installs nothing and needs no API key. It probes public endpoints of 11 AI services and compares routing exits for 20+ services against the same-family local exit. Please read it before running it:

curl -fsSL https://ipforai.cc/sh -o /tmp/ipforai-check.sh
less /tmp/ipforai-check.sh
sh /tmp/ipforai-check.sh

The cloudflare-mode routing probes in that script use the same cdn-cgi/trace approach shown above, so nothing in it is magic. Usage and output are documented at /cli, and the script mirror and JSON docs are on GitHub.

Takeaway

"My IP" isn't one value. It depends on the address family, the hostname, the matching rule and the client making the request. Before you blame your IP's "reputation," check that the service saw the IP you think it did. Ask the service side, check both families, and change one variable at a time.

If you've hit a dual-stack or routing edge case these checks don't explain, I'd like to hear about it in the comments.

I got tired of that. So I built a small data site and an open dataset that re-publishes the bulletin in a form you can actually query.

Site: yiminshuju.com
Full bulletin tables: yiminshuju.com/paiqi
Open data: github.com/xjokerabab/visa-bulletin-cn

What the site is (and isn’t)

yiminshuju.com aggregates:

• US green card Visa Bulletin dates (employment EB-1–EB-5 and family F1–F4)

• USCIS processing times by form and service center

• Canada Express Entry draw scores (where published)

• A light multi-country policy index of public numbers

It is data only — not a law firm, not a consultancy, not “we’ll get you a green card.” Every figure is tied back to an official source and stamped with an update date. If the government didn’t publish a field, the cell stays empty. No interpolated “estimates” dressed up as facts.

The part that usually confuses people: Table A vs Table B

The bulletin has two charts that look almost identical and mean very different things:

A priority date that is “current” on Table B is not the same as being ready for final action on Table A. Mixing them up is one of the most common ways people misread the bulletin. The paiqi page keeps A and B side by side for China / Worldwide / India so you can compare without flipping PDFs.

"C" generally means Current (no backlog for that category that month). Treat it as a status code, not a calendar date.

Why open data instead of another blog post

Screenshots rot. PDFs get replaced. Chat threads lose the source link.

The companion repo visa-bulletin-cn stores structured bulletin snapshots so you can:

• Diff month-over-month movement by category and chargeability

• Build your own alerts (“EB-2 China Table A moved”)

• Cite a stable URL instead of “see the screenshot I sent last Tuesday”

Sync happens after each new DOS bulletin drop; the site and the repo are meant to stay in step. Always treat the Department of State / USCIS originals as authoritative if anything disagrees.

A 30-second read of your own case

1. Confirm category and country of chargeability (e.g. China-mainland birth, EB-2).

2. Look at Table A — is your priority date earlier than the final action cutoff?

3. Look at Table B — only relevant if USCIS is accepting Chart B filings that month.

4. Separately check USCIS processing times for the form you actually filed (I-140, I-485, etc.). Processing time ≠ visa availability.

That’s it. No score, no “approval probability.”

Stack notes (for the curious)

Nothing exotic: scrape/parse official bulletin text into structured rows, render on a static-ish front end, keep the historical series in git. The interesting product decision wasn’t the framework — it was refusing to invent missing numbers. Empty beats estimated when you’re dealing with immigration cutoffs.

If you maintain your own pipeline, the repo is the cleaner input than OCR on a PDF.

Links

• Home / overview: https://yiminshuju.com

• Full Visa Bulletin tables: https://yiminshuju.com/paiqi/

• Open bulletin data: https://github.com/xjokerabab/visa-bulletin-cn

Caveats

This is a convenience layer over public government data. It is not legal advice, not a prediction of your case, and not a substitute for the official Visa Bulletin or USCIS notices. If you need a strategy call, talk to a licensed attorney — not a chart.

Questions, corrections, or “this category looks wrong” issues are welcome on the GitHub repo.