DHCP and DNS Explained for Internet Users in China
A practical guide to DHCP and DNS for reliable internet in China. Understand DNS poisoning, solve common connection issues, and learn why your VPN needs both.
A laptop joins the hotel Wi-Fi in Shanghai. The signal is strong, the Wi-Fi icon looks normal, and the browser still won't load Google, Slack, or a company dashboard overseas. Then a VPN connects, one app starts working, another hangs forever, and a video call turns into frozen faces and robotic audio.
That pattern feels random until the two systems underneath it are clear. DHCP gets the device onto the local network. DNS tells the device where websites and services live. In mainland China, that second step often causes trouble. A device can be fully connected to the local network and still be effectively cut off from the wider internet because name resolution is filtered, redirected, or leaked outside the VPN tunnel.
Most internet advice treats DHCP and DNS as boring background services. In China, they are operational survival topics. The difference between a stable workday and a broken one often comes down to which DNS servers the device received, whether the VPN replaced them correctly, and whether any traffic still escapes to the local resolver.
Table of Contents
- Your Digital Lifeline Understanding DHCP and DNS in China
- Getting Connected vs Finding Your Destination
- How Your Router Chooses Your Path to the Global Internet
- DNS Poisoning The Root of Your Connection Problems
- Troubleshooting Common Failures in China
- Security Risks Beyond Censorship
- Your Blueprint for a Stable Connection in China
Your Digital Lifeline Understanding DHCP and DNS in China
A lot of failed internet sessions in China start with a false assumption. People think, “The Wi-Fi connected, so the network is fine.” That only proves the first half of the journey worked.
DHCP and DNS are the pair that decide whether a device is merely attached to a local network or can reach the services needed for work. DHCP automates IP assignment, while DNS maps names to addresses and often has to stay synchronized with lease changes in modern environments. In Kea's DHCP-DDNS model, lease events generate NameChangeRequests so DNS records can be updated on behalf of DHCP servers, which shows how tightly linked the two systems have become in real operations (Kea DHCP-DDNS workflow).
That linkage matters because DHCP doesn't only hand out an IP address. It commonly provides the DNS server too, along with other settings the device needs to function. In a normal office or campus network, that automation is a convenience. In China, it can automatically place the device on a resolver path that won't behave like the open global internet.
Practical rule: If the device has Wi-Fi but overseas tools still fail, treat DNS as a first-check item, not a last resort.
This is why two people in the same building can have very different outcomes. One uses a VPN that fully controls DNS inside the tunnel. Another uses a VPN that only protects part of the traffic, leaving name lookups exposed to the local network. Both appear “connected.” Only one usually gets consistent access.
For anyone working from mainland China, the useful question isn't “Am I online?” It's “Who is resolving my queries, and is that resolution staying inside the path I trust?”
Getting Connected vs Finding Your Destination
The cleanest way to explain DHCP and DNS is this. DHCP gets the device an address on the local network. DNS helps it find the destination it wants to reach. Those jobs sound similar, but they fail in very different ways.
DHCP gives local identity
Think of DHCP as the building manager. A new device arrives and needs a temporary place in the building. DHCP assigns that device an address so the local network knows where it is. It can also hand out network configuration parameters such as subnet mask, default gateway, DNS server addresses, domain name, NTP, PXE boot details, and proxy auto-discovery settings, which reduces manual endpoint configuration (Univention on DHCP and DNS basics).
That matters more than most users realize. If DHCP gives the device a valid local address and gateway, the Wi-Fi icon looks healthy. If it also gives the wrong DNS settings, the user sees a confusing half-working state. Local apps may connect. Some domestic sites may load. International services may fail by name even though the network adapter looks fine.
DNS decides what the device can actually reach
DNS is closer to a directory and a map. Humans type names. Networks move packets to addresses. DNS performs that translation.
In China, that translation layer is where many user complaints begin. A device can receive a perfectly valid local configuration from the router and still get unusable answers when it asks for foreign services. That's why “connected to Wi-Fi” and “able to reach the global internet” are not the same condition.
A helpful way to separate the roles is this short comparison:
| Function | What it answers | Typical symptom when it breaks |
|---|---|---|
| DHCP | “Who am I on this local network?” | No useful local connectivity, missing network settings, unstable leases |
| DNS | “Where is the service I want?” | Websites time out, the wrong destination opens, some apps work while others don't |
A valid IP address only proves the device entered the building. It doesn't prove the map it was given is accurate.
That distinction is especially important with VPN use. A VPN can encrypt traffic well and still leave DNS handling weak. When that happens, the user gets the appearance of protection without reliable access. In China, weak DNS handling usually shows up fast.
How Your Router Chooses Your Path to the Global Internet
Every time a laptop joins a new network, there's a short negotiation before any browser tab opens. That negotiation is where the local network tells the device how to behave.
The four-step handoff that matters
DHCP uses the DORA process. That stands for Discover, Offer, Request, Acknowledge. It's the basic four-step exchange used to assign addresses efficiently, and it's the point where the network often tells the device which DNS servers to use as part of the overall configuration (BlueCat DNS statistics and DHCP context).
In plain terms, the flow looks like this:
- Discover. The device asks if any DHCP server is available.
- Offer. The network offers an address and related settings.
- Request. The device accepts that offer.
- Acknowledge. The network confirms the lease.
For most users, the important detail is hidden in step two. The offered package usually includes the DNS servers the device will trust by default. On a home network or hotel Wi-Fi in China, that often means the resolver path chosen by the local ISP or network operator.
Why VPN quality shows up here first
A strong VPN has to do more than encrypt the next web request. It has to override or safely contain the DNS settings that came from DHCP. If it doesn't, the device can still ask the local resolver for directions even while application traffic is trying to use the tunnel.
That's why some VPNs fail in such an uneven way. One tab opens. Another stalls. A chat app connects but file previews don't. The tunnel exists, yet the naming system underneath it is still partly local.
Modern infrastructure shows how close DHCP and DNS really are. DHCP-DDNS systems generate NameChangeRequests from lease events to update DNS records, which keeps device identity discoverable as addresses change. That same operational coupling is why a bad handoff between the two creates messy symptoms for end users.
For teams that want router-level coverage, what a VPN router changes is worth understanding. The main advantage isn't just convenience. It's consistency. A properly handled network edge can stop every new phone, laptop, and streaming box from inheriting a problematic DNS path the moment it joins Wi-Fi.
DNS Poisoning The Root of Your Connection Problems
When users in China say, “The internet is there, but the site won't open,” the underlying problem is often not bandwidth. It's DNS poisoning or DNS spoofing.
What poisoning looks like in daily use
A poisoned DNS path doesn't always return an obvious block page. Often it gives back a false answer, no useful answer, or an answer that leads nowhere. To the user, that looks like endless loading, connection resets, apps that fail only on sign-in, or websites that work on mobile data but not on office Wi-Fi.
That's why ordinary troubleshooting often wastes time. Refreshing the page won't fix a poisoned resolver. Changing browsers usually won't either. The device is asking the wrong authority for directions, and that authority is giving it unusable guidance.
A useful mental model is simple:
- Normal failure means the destination service is down.
- Poisoned DNS failure means the device was pointed in the wrong direction before the connection even started.
- VPN failure with DNS leak means the encrypted tunnel exists, but the device is still asking the local network where blocked services live.
When the resolver path is compromised, the browser is only reporting the last symptom. It isn't showing the real cause.
Why some VPNs still fail
A VPN that works well in China has to prevent DNS leaks. If the operating system keeps using the local DNS server for some lookups, blocked services can remain unreachable even though the VPN status shows “connected.”
This also explains why some apps work while others don't. Different applications handle DNS differently. Some rely strictly on system settings. Others cache results aggressively. Some switch between transport methods in ways that expose weak tunnel design. The result feels inconsistent because the failure is happening below the app layer.
For readers who want a security-focused explanation of how unusual DNS behavior can be identified on enterprise networks, ThreatCrush explains DNS tunneling detection. The topic is different from censorship, but it helps clarify why DNS is a powerful control point and why defenders monitor it so closely.
For blocked services specifically, a practical next step is understanding how users try to circumvent blocked sites and why resolver control matters as much as encryption.
Troubleshooting Common Failures in China
The most useful troubleshooting in China starts by separating symptoms that look similar but come from different causes. A weak VPN, a DNS leak, and a partial DHCP failure can all produce the same complaint: “The internet is broken.”
Three failure patterns worth separating
The VPN is connected, but Google or ChatGPT still won't load.
That usually points to DNS escaping the tunnel. The browser or app is still using the local resolver path, so blocked names never resolve cleanly. The tunnel may be fine. The naming layer isn't.
Video calls are choppy, but speed tests look acceptable.
That often means the path to the speed test server is fine while real-time application lookups or media relays are unstable. Teams, Zoom, Slack huddles, and similar tools depend on fast, consistent name resolution plus stable routes to multiple services. One broken DNS dependency can make calls degrade long before a generic download test looks bad.
Some apps work, others fail completely.
That can happen when cached lookups, split tunneling behavior, or mixed DNS handling create an uneven state across the system. It can also happen when DHCP assigned a lease but skipped part of the network settings. Microsoft documents a support case where a client received an IP lease but intermittently got no DNS server assigned, which breaks internet access despite DHCP appearing to work (Microsoft DHCP DNS assignment issue).
If one device works and another fails on the same Wi-Fi, compare the DNS settings first. Don't assume the VPN app alone tells the full story.
Quick DNS Troubleshooting Commands
| Operating System | Command | What to Look For |
|---|---|---|
| Windows | ipconfig /all | Check whether DNS servers are present, whether they change after the VPN connects, and whether the adapter in use matches expectations |
| macOS | scutil --dns | Review which resolvers are active and whether VPN-related resolvers appear above local ones |
| Linux | resolvectl status | Check the active link, current DNS servers, and whether the VPN interface is providing resolver settings |
These commands don't fix the issue by themselves. They answer a narrow question: which DNS servers is the device using right now?
A second useful check is consistency across networks. If office Wi-Fi fails but mobile hotspot works, the local DHCP handout or local DNS policy is a likely suspect. If both fail only when the VPN is on, the VPN client configuration deserves scrutiny.
For readers dealing with broader lease and server-response issues, Splash Access DHCP troubleshooting is a useful operational reference. The value isn't in any one vendor-specific trick. It's in keeping DHCP failure separate from DNS failure during diagnosis.
A practical fix order
A stable workflow usually follows this order:
- Confirm the lease: The device should have a valid local address, gateway, and DNS settings. If DNS is blank or inconsistent, the problem starts before the VPN.
- Connect the VPN and re-check DNS: The resolver should change in a way that matches the VPN design. If it doesn't, there may be a leak.
- Test by symptom type: Browser failure, app sign-in failure, and video-call degradation point to different layers. Don't treat them as the same bug.
- Compare another network: Mobile hotspot versus hotel Wi-Fi is often the fastest way to isolate whether the local DHCP and DNS path is the culprit.
That order saves time because it avoids random toggling. In China, random toggling is what burns most of the afternoon.
Security Risks Beyond Censorship
Not every DHCP and DNS problem in China comes from national filtering. Public Wi-Fi adds a second class of risk that matters for anyone handling client data, company logins, or internal tools.
Public Wi-Fi changes the threat model
On hotel, airport, café, and coworking networks, users usually trust whatever configuration appears automatically. That's exactly why rogue DHCP is dangerous. A malicious or misconfigured DHCP service can hand out bad DNS settings and subtly redirect traffic toward phishing pages, fake captive portals, or surveillance points.
The problem isn't theoretical. DHCP has authority at the moment a device joins the network. If a hostile actor controls that moment, the device can inherit a poisoned path before the user opens a single app.
DNS spoofing also exists outside censorship. Criminals use it to redirect users, intercept credentials, or impersonate familiar services. In practical terms, the effect looks similar to a censorship problem at first. The destination isn't what the user expected. The motive is different.
Why trusted DNS control matters
Securing the interaction between DHCP and DNS is an ongoing operational challenge. That includes secure dynamic updates to prevent unauthorized hostname changes and monitoring for unauthorized DHCP or DNS behavior so the network's live inventory stays trustworthy (Cycle on DNS DHCP and network services).
For everyday users, the lesson is straightforward:
- Don't trust public Wi-Fi defaults: Automatic settings are convenient, not safe.
- Use a VPN that controls DNS end to end: Encryption without resolver control leaves a major gap.
- Reduce local attack surface: Consumer router features can expose unnecessary services. For home or small-office setups, whether UPnP should be on or off is part of the same broader hygiene question.
A stable setup in China isn't only about reaching blocked sites. It's also about making sure the network that “helpfully” configures the device isn't steering it somewhere unsafe.
Your Blueprint for a Stable Connection in China
The practical version of DHCP and DNS is easy to remember. DHCP gets the device onto the local network. DNS decides whether the device can find the services it needs.
In mainland China, that distinction matters every day. Local connectivity can look healthy while global access is filtered, redirected, or leaked outside a VPN tunnel. That's why users so often misdiagnose the problem as “slow internet” when the actual issue is resolver control.
The reliable approach is disciplined, not fancy:
- Accept that local Wi-Fi only solves local attachment
- Verify which DNS servers the device is using
- Use a VPN that keeps DNS inside the trusted tunnel
- Treat partial app failures as a resolver clue, not a mystery
- Be cautious on public Wi-Fi, where DHCP itself may be untrustworthy
China's internet environment rewards users who understand the handoff between local network access and global name resolution. Once that handoff is visible, a lot of “random” breakage stops looking random at all.
Throughwire is built for people who need dependable global internet access from mainland China without babysitting settings all day. If reliable DNS handling, stable international routing, and router-level deployment matter, Throughwire is worth evaluating for individual, team, and enterprise use.