Network

• A Few Ways to Safely Use Public IPv6
• Using Common DDNS Subdomains May Cause China Telecom Broadband Service Degradation
• Compliance Discussion of Reverse Proxy in Home Networks
• Some Characteristics of China Telecom IPv6
• Why we should not think of UDP in terms of TCP
• Troubleshooting Linux Network Issues
• How to Improve Network Experience with a Self-Hosted DNS Service
• Bypassing ChatGPT VPN Detection

A Few Ways to Safely Use Public IPv6

Some people need to “go home” via public IPv6. Unlike Tailscale/Zerotier et al., which rely on NAT traversal to create direct tunnels, native IPv6 offers a straight-through connection. Cellular networks almost always hand out global IPv6 addresses, so “going home” is extremely convenient.

I previously posted Using Common DDNS Sub-domains on Home Broadband May Downgrade Telecom Service describing a pitfall with IPv6: domains get crawled. Exposing your domain is basically the same as exposing your IPv6 address. Once scanners find open services and inbound sessions pile up, the ISP may silently throttle or downgrade your line.

That thread mentioned domain scanning but not cyberspace scanning—which ignores whatever breadcrumbs you leave and just brute-forces entire address blocks. This is much harder to defend against.

Cyberspace scanning usually includes the following steps:

• Host-alive detection using ARP, ICMP, or TCP to list responsive IPs.
• Port / service discovery to enumerate open ports and identify service names, versions, and OS signatures.
• Operating-system fingerprinting by analyzing packet replies.
• Traffic collection to spot anomalies or attack patterns.
• Alias resolution mapping multiple IPs to the same router.
• DNS recon reverse-resolving IPs to domain names.

Below are a few methods to stay off those scanners:

1. Have your internal DNS server never return AAAA records.
2. Allow internal services to be reached only via domain names, never by raw IP.
3. Use a private DNS service such as AdGuardPrivate.

Prevent AAAA Records on the Internal DNS

When you browse the web, every outbound connection can leak your source IPv6. If a firewall isn’t in place, that address enters the scanners’ high-priority IP pools.

Even scanning only the last 16 bits of a /56 prefix becomes a smaller task once the prefix is leaked.

After years of IPv6 use, I have seen no practical difference between IPv6 and IPv4 for day-to-day browsing. So we can sacrifice IPv6 for outbound traffic and reserve it solely for “go home” access.

How to block AAAA records

Configure your internal DNS resolver to drop all AAAA answers.

Most home setups run AdGuard Home—see the screenshot:

Once applied, local devices reach the outside world over IPv4 only.

Never Expose Services by IP

Exposing a service on a naked port makes discovery trivial. When you start a service, avoid binding to 0.0.0.0 and ::; almost every tutorial defaults to 127.0.0.1 plus ::1 for good reason—listening on public addresses is risky.

Reverse-proxy only by domain name

nginx example

Set server_name to an actual hostname instead of _ or an IP.

server {
    listen 80;
    server_name yourdomain.com; # replace with your real domain

    # 403 for anything not the correct hostname
    if ($host != 'yourdomain.com') {
        return 403;
    }

    location / {
        root /path/to/your/web/root;
        index index.html index.htm;
    }

    # additional config...
}

IIS example

Remember to specify the exact hostname—never leave the host field blank.

Use a private DNS service

Create spoofed hostnames that resolve only inside your own DNS.

Benefits:

• Hostnames can be anything—no need to buy a public domain.
• If a fake hostname leaks, the attacker still has to point their DNS resolver at your private server.
• Scanning the IP alone is useless: one must also (a) know the fake name, (b) set their resolver to your DNS, (c) include that name in each request’s Host header. All steps have to succeed.

sequenceDiagram
  participant Scanner as Scanner
  participant DNS as Private DNS
  participant Service as Internal Service

  Scanner->>DNS: 1. Find private DNS address
  Scanner->>DNS: 2. Query fake hostname
  DNS-->>Scanner: 3. Return internal IP
  Scanner->>Service: 4. Construct Host header
  Note right of Service: Denied if Host ≠ fake hostname
  alt Correct Host
    Service-->>Scanner: 5a. Response
  else Wrong Host
    Service-->>Scanner: 5b. 403
  end

This significantly increases the scanning cost.

You can deploy AdGuardPrivate (almost a labeled AdGuard Home) or Tencent’s dnspod purely for custom records. Functionality differs, so evaluate accordingly.

Summary

1. Prevent the internal DNS from returning AAAA records

   • Pre-reqs
     • Public IPv6 prefix
     • Internal DNS resolver
   • Steps
     • Drop AAAA answers

2. Reach internal services only via domain names

   • Pre-reqs
     • You own a domain
     • Registrar supports DDNS
     • Local reverse proxy already running
   • Steps
     • Enable DDNS task
     • Host-based access only

3. Spin up a private DNS

   • Pre-reqs
     • Private DNS service with custom records and DDNS
   • Steps
     • Enable DDNS task
     • Map fake hostnames to internal services

Finally:

• Tailscale/Zerotier that successfully punch through are still the simplest and safest way to go home.
• Don’t hop on random Wi-Fi—you’ll give everything away in one shot. Grab a big-data SIM and keep your faith with the carrier for now. (Cheap high-traffic SIM? DM me. Not really.)

Using Common DDNS Subdomains May Cause China Telecom Broadband Service Degradation

I have been troubleshooting IPv6 disconnections and hole-punching failures for over three months. I’ve finally identified the root cause; here’s the story.

My First Post Asking for Help—IPv6 Disconnections

IPv6 had been working perfectly. Without touching any settings, and even though every device had its own IPv6, it suddenly lost IPv6 connectivity entirely.

curl 6.ipw.cn returned nothing, and both ping6 and traceroute6 2400:3200::1 failed.

My ONT was bridged to the router, and I could still obtain the router’s own IPv6—one that could still reach the IPv6 Internet.

I received a /56 prefix, and all downstream devices received addresses within 240e:36f:15c3:3200::/56, yet none could reach any IPv6 site.

I suspected the ISP had no route for 240e:36f:15c3:3200::, but I couldn’t prove it.

Someone suggested excessive PCDN upload traffic was the culprit, but upload volume was minimal and PCDN wasn’t enabled.

Another possibility was that using Cloudflare and Aliyun ESA reverse proxies had caused it.

My Second Post—Finding a Direct Cause

I confirmed that at least some regions of China Telecom will downswitch service when they see many inbound IPv6 HTTP/HTTPS connections, manifesting as:

• Fake IPv6: You still get a /56, every device keeps its IPv6, but traceroute lacks a route, so IPv6 is de-facto unusable.
• Fake hole- punch: Tailscale reports its connection is direct, yet latency is extreme and speed is terrible.

Every time I disabled Cloudflare/Aliyun ESA proxying and rebooted the router a few times, both real IPv6 connectivity and true direct Tailscale worked again.

Still Disconnects After Disabling Reverse Proxy

Even with proxy/CDN disabled—complete direct origin access—I still had occasional outages lasting hours.

Perhaps my domain had leaked, or bots were scanning popular subdomains with a steady HTTP attack.

When I disabled DNS resolution for the DDNS hostname outright, IPv6 came back after a while, and Tailscale hole-punching was again direct and stable.

Since then those disconnections never returned.

My Final Recommendation

Avoid using commonplace DDNS subdomains, such as:

• home.example.com
• nas.example.com
• router.example.com
• ddns.example.com
• cloud.example.com
• dev.example.com
• test.example.com
• webdav.example.com

I had used several of these; it seems they are continuously scanned by bots. The resulting flood of requests triggered China Telecom’s degradation policy, making my IPv6 unusable and blocking hole-punching.

As you already know, hiding your IP matters in network security; the same goes for protecting the domain you use for DDNS—that domain exposes your IP as well.

If you still need public services, you have two practical choices:

1. Proxy/Front-end relay—traffic hits a VPS first, then your home server. Latency and bandwidth suffer because traffic takes a detour.
2. DDNS direct—everything connects straight to you. Performance is much better; this is what I recommend. For personal use the number of connections rarely hits the limit, but once the domain becomes public the bots will ramp it up quickly.

Proxy Relay (Reverse Proxy)

Cloudflare Tunnel

Use Cloudflare’s Tunnel so you won’t see the dozens or hundreds of IPs typical of ordinary reverse proxies.

Tailscale or ZeroTier

Build your own VPN, put a VPS in front, and reach your LAN services through the VPN. This avoids excessive simultaneous connections.

DDNS Direct Scheme

Public DNS

Generate a random string—like a GUID—and use it as your DDNS hostname. It’s impossible to remember, but for personal use that’s acceptable. Judge for yourself.

Private DNS

Run your own DNS service, e.g.:

• AdguardPrivate
• dot.pub

Configure it to serve your DDNS records; only people who can query your private DNS will resolve the custom IP.

In this model you can use common DDNS names, but take care never to expose the address of your private DNS server.

Afterthought

Rumor has it that naming a subdomain speedtest might provide a mysterious boost.

Compliance Discussion of Reverse Proxy in Home Networks

Background

About 90 days ago, I encountered an IPv6 connectivity issue with China Telecom Hubei. After long-term observation and analysis, here are the findings.

Problem Analysis

Two initial suspected causes:

1. PCDN usage detection

   • No active use of PCDN
   • Only a small amount of BitTorrent downloads
   • Upload throttling has been applied, yet the problem persists

2. Home server acting as blog origin

   • Uses Cloudflare origin rules specifying a port
   • May be deemed “commercial behavior” by the ISP

After three months of validation, the issue is more likely triggered by exposing HTTP/HTTPS service ports to the public Internet.

Specific Symptoms

1. IPv6 anomalies:

   • /56 prefix is assigned
   • Devices receive global IPv6 addresses
   • Yet external network access fails
   • Only the router in bridge mode behind the optical modem retains normal IPv6

2. Tailscale connection anomalies:

   • The source server reports direct connectivity but with excessive latency (~400 ms)
   • Other devices go through relays and obtain lower latency (~80 ms)

ISP Policy Analysis

Telecom carriers in certain regions apply service degradation to inbound-heavy HTTP/HTTPS connections:

1. IPv6 service downgrade

   • Addresses are still assigned
   • Routing tables are missing
   • Effective Internet access is blocked

2. P2P connection throttling

   • Tailscale shows direct connections
   • Actual latency is abnormally high
   • Bandwidth is restricted

Solutions

1. Disable reverse-proxy services:

   • Deactivate Cloudflare/Alibaba Cloud ESA reverse proxies
   • After multiple router reboots, connectivity returns to normal

2. Prevent domain scanning: Avoid these common sub-domains:

   - home.example.com
   - ddns.example.com
   - dev.example.com
   - test.example.com
   

3. Best practices:

   • Use a GUID to generate random sub-domains
   • Refrain from predictable or common sub-domain naming
   • Rotate domains periodically to reduce scanning risk

Some Characteristics of China Telecom IPv6

• Some Characteristics of China Telecom IPv6

• Some Characteristics of China Telecom IPv6

IPv6 has been fully rolled out nationwide; the IPv6 address pool is large enough for each of every individual’s devices to obtain its own IPv6 address.
To actually use IPv6 at home, the entire stack of devices must all support IPv6. Because the rollout has been underway for many years, virtually every device bought after 2016 already supports IPv6.

The full stack includes: metro equipment → community router → home router (ONT/router) → end device (phones, PCs, smart TVs, etc.)

This article does not discuss the standard IPv6 protocol itself; it focuses only on certain characteristics of China Telecom’s IPv6.

Address Allocation

First, the methods of address assignment. IPv6 offers three ways to obtain an address: static assignment, SLAAC, and DHCPv6.
Hubei Telecom uses SLAAC, meaning the IPv6 address is automatically assigned by the device. Because the carrier’s IPv6 pool is enormous, address conflicts are impossible.

Telecom IPv6 addresses are assigned at random and recycled every 24 h. If you need inbound access, you must use a DDNS service.

Firewall

At present it can be observed that common ports such as 80, 139, 445 are blocked—mirroring the carrier’s IPv4 firewall. This is easy to understand: operator-level firewalls do protect ordinary users who lack security awareness. In 2020, China Telecom IPv6 was fully open, but now certain common ports have been blocked.

Port 443 is occasionally accessible within the China Telecom network but blocked for China Mobile and China Unicom. Developers must keep this in mind. A service that works fine in your dev environment—or that your phone on the China Telecom network can reach—may be unreachable from a phone on a different carrier.

Based on simple firewall testing, developers are strongly advised not to trust operator firewalls. Serve your application on a five-digit port.

Furthermore, China Telecom’s firewall does not block port 22, and Windows Remote Desktop port 3389 is likewise open.
Consequently, remote login is possible—introducing obvious risks.

Once attackers obtain the IP or DDNS hostname, they can start targeted attacks; brute-force password cracking can grant control of the device. The domain name can also reveal personal information—name, address, etc.—and attackers may use social-engineering tactics to gather even more clues to speed up their intrusion.

It is recommended to disable password authentication for ssh and rely only on key-based login, or to use a VPN, or to employ a jump host for remote access.

Why we should not think of UDP in terms of TCP

• Why we should not think of UDP in terms of TCP

Why we should not think of UDP in terms of TCP?

Structural Differences

TCP has many concepts: connection establishment, resource usage, data transfer, reliable delivery, retransmission based on cumulative ACK-SACK, timeout retransmission, checksum, flow control, congestion control, MSS, selective acknowledgements, TCP window scale, TCP timestamps, PSH flag, connection termination.

UDP has virtually none of these facilities; it is only slightly more capable than the link layer in distinguishing applications. Because UDP is extremely simple, it is extremely flexible.

If it can happen, it will

Murphy’s law:

If anything can go wrong, it will.

Conventional wisdom suggests that UDP suits games, voice, and video because a few corrupt packets rarely matter. The reason UDP is chosen for these use-cases is not that it is the perfect match, but that there are unsolved problems for TCP that force services to pick the less-featured UDP. Saying “a few corrupt packets do not disturb the service” actually means that TCP worries about packet correctness while UDP does not; UDP cares more about timeliness and continuity. UDP’s defining trait is its indifference to everything TCP considers important—factors that harm real-time performance.

In code, UDP only needs one socket bound to a port to begin sending and receiving. Usually the socket lifetime matches the port lifetime.

Therefore, I can use UDP like this:

1. Send random datagrams to any IP’s any port and see who replies.
2. Alice sends a request from port A to port B of Bob, Bob responds from port C to Alice’s port D.
3. Alice same as above, but Bob asks Charlie to answer from port C to Alice’s port D.
4. Alice sends a request from port A to port B, but spoofs the source address to Charlie’s address; Bob will reply to Charlie.
5. Both sides agree to open ten UDP ports and send as well as receive on each one concurrently.

Of course none of these patterns can exist in TCP, but in UDP, because they are possible, sooner or later someone will adopt them. Expecting UDP to behave like TCP is therefore idealistic; reality cannot be fully enumerated.

UDP datagrams are extremely lightweight and highly flexible; the idea of a “connection” does not exist at the protocol level, so you must invent your own notion of a UDP connection. Different definitions were tried, yet none could always unambiguously describe direction from a single datagram; we must accept ambiguity. After all, no official “UDP connection” standard exists—when parties hold different definitions, mismatched behaviours are inevitable.

UDP from the client’s viewpoint

Voice or video can suffer packet loss, but the loss pattern has very different effects on user experience. For example, losing 30 % of packets evenly or losing 30 % all within half a second produces drastically different experiences; the former is obviously preferable. However, UDP has no built-in flow control to deliberately throttle traffic. Although UDP is often described as “best-effort”, the details of that effort still determine the outcome.

UDP from the provider’s viewpoint

For TCP attacks, the client must invest computational resources to create and maintain connections—attackers thus incur costs. With UDP, the attacker’s overhead is much lower; if the goal is just to burn server bandwidth, UDP is perfect. Suppose the service buys 100 GB of unmetered traffic but only processes 10 MB/s while accepting 1 GB/s—90 % of the arriving traffic is junk, yet it is still billable. Providers should avoid such situations.

UDP from the ISP’s viewpoint

End-to-end communication comprises multiple endpoints and transit paths. We usually focus only on client and server viewpoints, but the ISP’s perspective matters too. Under DDoS, we pay attention to server capacity, ignoring the ISP’s own finite resources. The server may ignore useless requests, yet the ISP has already paid to carry them. When we perform stress tests we often report “packet loss”, overlooking that the number reflects loss along the entire path—not just at the server. ISPs drop packets as well. From the ISP’s view, the service purchased 1 MB/s, but the client send rate is 1 GB/s; they both pay nothing for the wasted bandwidth—the ISP bears the cost. To avoid that, ISPs implement UDP QoS. Compared to TCP’s congestion control, ISPs can just drop UDP. In practice the blunt approach is to block traffic on long-lived UDP ports. Field tests of WeChat calls show that each call uses multiple ports with one UDP port talking to six different UDP ports on the same server—likely a countermeasure to ISP port blocks.

Summary

UDP’s flexibility usually means there are several legitimate methods to reach a goal; as long as the program eventually communicates stably, however bizarre it may appear compared with TCP, it is “the way it is”. We therefore cannot force TCP concepts onto UDP. Even when we invent a new “UDP connection” for product design, we must expect and gracefully accept errors—the ability to tolerate errors is UDP’s core feature, an advantage deliberately chosen by the service, not a flaw we have to live with.

Further reading

• Learning the principles of QoS in 20 000 words
• Transmission Control Protocol
• User Datagram Protocol

Troubleshooting Linux Network Issues

Troubleshooting Tools

How to Improve Network Experience with a Self-Hosted DNS Service

Network Quality vs. Network Experience

Do nothing, and you’ll already enjoy the best network experience.

First, note that “network quality” and “network experience” are two different concepts. Communication is a process involving many devices. The upload/download performance of a single device can be termed network quality, while the end-to-end behavior of the entire communication path is what we call network experience.

Measuring Network Quality

Evaluating network quality usually involves several metrics and methods. Common ones include:

1. Bandwidth – the capacity to transfer data, conventionally expressed in bits-per-second. Higher bandwidth generally indicates better quality.
2. Latency – the time a packet takes to travel from sender to receiver. Lower latency means faster response.
3. Packet-loss rate – the proportion of packets lost en route. A lower rate suggests higher quality.
4. Jitter – variability in packet arrival times. Smaller jitter means a more stable network.
5. Throughput – the actual data volume successfully transported in a given period.
6. Network topology – the physical or logical arrangement of network nodes; good design improves quality.
7. Quality-of-Service (QoS) – techniques such as traffic shaping and priority queues that ensure acceptable service levels.
8. Protocol analysis – examining traffic with tools like Wireshark to diagnose bottlenecks or errors.

Combined, these indicators give a complete picture of network performance and improvement opportunities. Carriers need these details, but ordinary users often need only a decently priced modern router—today’s devices auto-tune most of these knobs.

Measuring Network Experience

The first factor is reachability—being able to connect at all. A DNS service must therefore be:

• Comprehensive: its upstream resolvers should be authoritative and able to resolve the largest possible set of names.
• Accurate: results must be correct and free from hijacking or pollution returning advertisement pages.
• Timely: when an IP changes, the resolver must return the fresh address, not a stale record.

Next comes the network quality of the resolved IP itself.

Because service quality varies strongly with region, servers geographically closer to the client often offer better performance.

Most paid DNS providers support Geo-aware records. For example, Alibaba Cloud allows:

(1) Carrier lines: Unicom, Telecom, Mobile, CERNet, Great Wall Broadband, Cable WAN—down to province level.
(2) Overseas regions: down to continent and country.
(3) Alibaba cloud lines: down to individual regions.
(4) Custom lines: define any IP range for smart resolution.

“(distribution-map-placeholder)”

By resolving IPs based on location, distant users reach nearby servers automatically—boosting experience without them lifting a finger.

In practice, service providers optimize UX based on the client’s real address. For most users, doing nothing gives the best network experience.

Choosing Upstream Resolvers for Self-Hosted DNS

Nearly every Chinese-language guide tells you to pick large authoritative resolvers—Alibaba, Tencent, Cloudflare, Google—because they score high on reachability (comprehensive, accurate, timely). Yet they do not guarantee you the nearest server.

There’s historical context: Chinese ISPs once hijacked DNS plus plaintext HTTP to inject ads. Today, with HTTPS prevalent, this is far less common, though some last-mile ISPs may still try it. Simply switching resolvers to random IPs won’t save you from hijacks directed at UDP 53.

Another user niche cares about content filtering; some providers return bogus IPs for “special” sites. Authoritative resolvers rarely exhibit this behavior.

So three problems arise:

1. IP contamination
2. DNS hijacking
3. Optimal service experience

Authoritative resolvers fix (1); encrypted transports (DoT/DoH/QUIC) mitigate (2).

For (3) you must go back to your carrier’s default DNS. As we said: “Do nothing, and you’ll already enjoy the best network experience.”

But if you’re a perfectionist or a special user, the sections below show how to configure AdGuard Home and Clash to satisfy all three concerns at once.

Authoritative yet “Smart” DNS

AdGuard Home Configuration

AdGuard Home (ADG) is an ad-blocking, privacy-centric DNS server. It supports custom upstream resolvers and custom rules.

ADG’s default mode is load-balancing: you list several upstreams; ADG weights them by historical response speed and chooses the fastest. In simple terms, it will favor the quickest upstream more often.

Pick the third option instead: “Fastest IP address”.

“(ui-screenshot-placeholder)”

Result: ADG tests the IPs returned by each upstream and replies with whichever has the lowest latency. Below are ordinary results for bilibili.com:

“(ordinary-results-screenshot-placeholder)”

Without this option, ADG would hand every IP back to the client: some apps pick the first, others the last, others pick at random—possibly far from optimal.

With “Fastest IP address” enabled:

“(optimized-results-screenshot-placeholder)”

That alone improves network experience.

Why isn’t “Fastest IP address” the default?
Because waiting for all upstream answers means query time equals the slowest upstream. If you mix a 50 ms Ali server with a 500 ms Google one, your upstream delay becomes ~500 ms.

So users must balance quality vs. quantity. I suggest keeping two upstreams only: one authoritative (https://dns.alidns.com/dns-query) plus your local carrier’s DNS.

Carrier DNS IPs differ by city; look yours up here or read them from your router’s status page:

“(router-dns-screenshot-placeholder)”

Clash Configuration

Users with special needs who still want optimal routing can delegate DNS handling to Clash’s dns section.

nameserver-policy lets you assign different domains to different resolvers. Example:

dns:
  default-nameserver:
    - tls://223.5.5.5:853
    - tls://1.12.12.12:853
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://one.one.one.one/dns-query
    - https://dns.google/dns-query
  nameserver-policy:
    "geosite:cn,private,apple":
      - 202.103.24.68 # your local carrier DNS
      - https://dns.alidns.com/dns-query
    "geosite:geolocation-!cn":
      - https://one.one.one.one/dns-query
      - https://dns.google/dns-query

Meaning:

• default-nameserver – used solely to resolve hostnames of DNS services in the nameserver list.
• nameserver – standard resolvers for ordinary queries.
• nameserver-policy – overrides above resolvers for specific groups of domains.

Thanks for Reading

If this post helped you, consider giving it a thumbs-up. Comments and discussion are always welcome!

Bypassing ChatGPT VPN Detection

How to handle the ChatGPT error messages
“Unable to load site”
“Please try again later; if you are using a VPN, try turning it off.”
“Check the status page for information on outages.”

Foreword

ChatGPT is still the best chatbot in terms of user experience, but in mainland China its use is restricted by the network environment, so we need a proxy (literally a “ladder”) to reach it. ChatGPT is, however, quite strict in detecting proxies, and if it finds one it will simply refuse service. This article explains a way around that detection.

Some people suggest switching IPs to evade a block, yet the geolocations we can get from our providers already belong to supported regions, so this is not necessarily the real reason for denial of service.

Others argue that popular shared proxies are too easy to fingerprint and advise buying more expensive “uncrowded” ones, yet this is hardly a solid argument—IPv4 addresses are scarce, so even overseas ISPs often allocate ports via NAT. Blocking one address would hit a huge community, something that a service as widely used as ChatGPT surely would not design for.

For a public service, checking source-IP consistency makes more sense. Paid proxy plans typically impose data or speed limits, so most users adopt split-routing: they proxy only when the destination is firewalled, letting non-filtered traffic travel directly. This choice of paths can result in inconsistent source IPs. For example, Service A needs to talk to Domains X and Y, yet only X is firewalled; the proxy will be used for X but not Y, so A sees the same request coming from two different IPs.

Solving this source-IP inconsistency will bypass ChatGPT’s “ladder” identification.

Proxy rules usually include domain rules, IP rules, and so on.

Remember that the result of a domain resolution varies by region—if you are in place A you get a nearby server, and in place B you may get another. Therefore, DNS selection matters.

DNS Selection

Today there are many DNS protocols; UDP:53 is so outdated and insecure that China lists DNS servers as a top-level requirement for companies. Such rules arose from decades of carriers employing DNS hijacking plus HTTP redirection to insert advertisements, deceiving many non-tech-savvy users and leading to countless complaints. Although today Chrome/Edge automatically upgrade to HTTPS and mark plain HTTP as insecure, many small neighbourhood ISPs and repackaged old Chromium versions persist, so DNS and HTTP hijacking still occur.

Hence we need a safe DNS protocol to avoid hijacking. In my experience Alibaba’s public 223.5.5.5 works well. Of course, when I mention 223.5.5.5 I do not mean plain UDP but DoH or DoT. Configure with tls://223.5.5.5 or https://dns.alidns.com/dns-query.

Alidns rarely gets poisoned—only during certain sensitive periods. You can also use my long-term self-hosted resolver tls://dns.jqknono.com, upstreaming 8.8.8.8 and 1.1.1.1, with cache acceleration.

Domain Rules

The detection page first visited runs probing logic, sending requests to several domains to check the source IP, so domain routing must remain consistent.

Besides its own, ChatGPT relies on third-party domains such as auth0, cloudflare, etc.

Add the following rules by hand:

# openai
- DOMAIN-SUFFIX,chatgpt.com,PROXY
- DOMAIN-SUFFIX,openai.com,PROXY
- DOMAIN-SUFFIX,openai.org,PROXY
- DOMAIN-SUFFIX,auth0.com,PROXY
- DOMAIN-SUFFIX,cloudflare.com,PROXY

How to test domain rules

The domains above may evolve as ChatGPT’s services change; here is how to discover them yourself.

1. Open a private/Incognito window to avoid caches/cookies.
2. Press F12 to open DevTools, switch to the Network tab.
3. Visit chat.openai.com or chatgpt.com.
4. The following screenshot shows the domains used at the time of writing:

Adding just those domains may still be insufficient. Inspect each aborted request: the challenge response’s Content-Security-Policy lists many domains. Add every one to the proxy policy.

# openai
- DOMAIN-SUFFIX,chatgpt.com,PROXY
- DOMAIN-SUFFIX,openai.com,PROXY
- DOMAIN-SUFFIX,openai.org,PROXY
- DOMAIN-SUFFIX,auth0.com,PROXY
- DOMAIN-SUFFIX,cloudflare.com,PROXY
# additional
- DOMAIN-SUFFIX,oaistatic.com,PROXY
- DOMAIN-SUFFIX,oaiusercontent.com,PROXY
- DOMAIN-SUFFIX,intercomcdn.com,PROXY
- DOMAIN-SUFFIX,intercom.io,PROXY
- DOMAIN-SUFFIX,mixpanel.com,PROXY
- DOMAIN-SUFFIX,statsigapi.net,PROXY
- DOMAIN-SUFFIX,featuregates.org,PROXY
- DOMAIN-SUFFIX,stripe.com,PROXY
- DOMAIN-SUFFIX,browser-intake-datadoghq.com,PROXY
- DOMAIN-SUFFIX,sentry.io,PROXY
- DOMAIN-SUFFIX,live.net,PROXY
- DOMAIN-SUFFIX,live.com,PROXY
- DOMAIN-SUFFIX,windows.net,PROXY
- DOMAIN-SUFFIX,onedrive.com,PROXY
- DOMAIN-SUFFIX,microsoft.com,PROXY
- DOMAIN-SUFFIX,azure.com,PROXY
- DOMAIN-SUFFIX,sharepoint.com,PROXY
- DOMAIN-SUFFIX,gstatic.com,PROXY
- DOMAIN-SUFFIX,google.com,PROXY
- DOMAIN-SUFFIX,googleapis.com,PROXY
- DOMAIN-SUFFIX,googleusercontent.com,PROXY

IP Rules

If the site still refuses to load after the steps above, IP-based detection may also be in play. Below are some IPs I intercepted; they may not fit every region, so test on your own.

# openai
- IP-CIDR6,2606:4700:4400::6812:231c/96,PROXY
- IP-CIDR,17.253.84.253/24,PROXY
- IP-CIDR,172.64.152.228/24,PROXY
- IP-CIDR,104.18.35.28/16,PROXY

How to test IP rules

Know your proxy tool. Open its connection log, watch the new connections as you reproduce the steps, then add the IPs you see.

A quick guide:

1. Open a private/Incognito window.
2. Visit chat.openai.com or chatgpt.com.
3. Monitor the new connections in your proxy client and copy their IPs into rules.

Protocol Rules

QUIC is an encrypted UDP protocol, and ChatGPT makes heavy use of QUIC traffic. Therefore both client and server must support UDP forwarding; many do not. Even with support, you must explicitly enable it—some clients default to not proxy UDP traffic. If unsure about UDP, either block QUIC in the proxy client or disable it in the browser; the browser will automatically fall back to HTTP/2 over TCP. QUIC provides smoother performance; feel free to experiment.

The simplest config – whitelist mode

Set direct connections only for Chinese IPs and proxy everything else. This grants reliable ChatGPT access and also covers other foreign services.

The downside is higher data consumption and dependency on your proxy’s quality. If you trust your proxy’s network, give this a shot.

Of course, do remember to enable UDP forwarding.