Here we will introduce some advanced usage tips for private services.
This is the multi-page printable view of this section. Click here to print.
Advanced Features
- 1: Blocked Application List
- 2: ECS Boosts CDN Access Speed
- 3: DDNS Dynamic Resolution
- 4: DNS Split-Horizon Configuration Guide
- 5: Using Custom Device Names
- 6: Faster Request Response
- 7: Set Up Trusted Upstream Providers
1 - Blocked Application List
It is important not to confuse this with blacklists, which are usually used to block ads, privacy trackers, malware, etc. The Blocked Application List is for completely preventing the use of specified applications.
It is typically combined with a schedule to build personal habits and avoid addiction. Commonly used for minors’ habit formation—for example, prohibiting social media and games during study hours. It can also be used for adult self-discipline, such as banning social media and games during work hours.
This service provides pre-configured rules based on popular apps in each country. Because popular culture changes and companies evolve, these lists may become outdated, but we are committed to ongoing maintenance.
If you find that an app in the list is not fully blocked, or if you need to add a recently popular app, please contact us and we will handle it promptly.
Need help?
Contact on WeChat
private6688
or
Send email
service1@nullprivate.com
Please describe your issue in detail, and we will respond as soon as possible.
Country/Region | Application List |
---|---|
Global | Global Application List |
Mainland China | Mainland China Application List |
2 - ECS Boosts CDN Access Speed
NullPrivate supports ECS, delivering more precise resolution and optimizing your network experience.
What is ECS (Extended Client Subnet)?
ECS (Extended Client Subnet) is a DNS protocol extension that allows a DNS resolver (such as your NullPrivate server) to pass part of the client’s IP address information to the authoritative DNS server. This enables the authoritative server to provide more accurate DNS responses based on the client’s network location.
How ECS Works
Traditional DNS Query: Without ECS, the DNS resolver only sends its own IP address to the authoritative DNS server. This forces the authoritative server to make resolution decisions based on the resolver’s location (usually a data center), which can yield sub-optimal results.
ECS-enabled DNS Query: When ECS is enabled, the DNS resolver includes a portion of the client’s IP address (the subnet) in the DNS query. For example, if the client’s IP is
203.0.113.45
, the resolver might send203.0.113.0/24
as ECS information.Authoritative Server Response: Upon receiving a query containing ECS information, the authoritative DNS server can use it to select the IP address best suited to the client—typically the server geographically closest to the client.
Benefits of ECS
- Faster Response Times: By directing clients to the nearest server, ECS reduces latency and improves application responsiveness.
- Enhanced User Experience: Faster response times create a smoother, more enjoyable online experience.
- More Effective CDN Usage: Content Delivery Networks (CDNs) can leverage ECS to direct users to the optimal content server, boosting efficiency and lowering costs.
- Bypass Local Resolver Limitations: Some local ISP DNS servers may have issues such as resolution errors or domain hijacking. ECS can bypass these limitations to obtain more accurate resolution results.
Why Use ECS with NullPrivate?
As a private DNS server, NullPrivate can be configured to use upstream DNS servers for domain resolution. With ECS enabled, NullPrivate can pass your client subnet information to those upstream servers, yielding more accurate resolution results.
3 - DDNS Dynamic Resolution
What is DDNS?
DDNS (Dynamic DNS) lets you bind a fixed domain name to a dynamic IP address, ideal for home broadband users who need to access internal devices such as NAS units, smart-home controllers, etc.
Features
- Easy to use: Automatic updates with a single script
- Zero extra cost: No need to purchase a domain
- High reliability: Powered by NullPrivate’s DNS infrastructure
- Fast propagation: DNS records take effect instantly after update, no waiting for propagation
Getting Started
You can find the DDNS script download link under Filters -> DNS rewrites
.
FAQ
How do I verify it’s working?
Run ping your-domain.name
to confirm the domain resolves to your current IP address.
Alternatively, log in to the service dashboard and check Filters -> DNS rewrites.
How do I schedule automatic updates?
Windows Task Scheduler
- Open Task Scheduler
- Create a basic task
- Set the trigger frequency (recommended 15–30 minutes)
- Choose PowerShell as the program and enter the full script command in the arguments
Linux Cron Job
Add the following to crontab (runs every 15 minutes):
*/15 * * * * /path/to/update_dns.sh https://xxxxxxxx.adguardprivate.com admin:password123 nas.home
Notes
- Keep your username and password secure to avoid leaks
- It’s recommended to add the update script to your system scheduler for automatic execution
- If resolution doesn’t update promptly, check network connectivity and verify credentials
4 - DNS Split-Horizon Configuration Guide
DNS Split-Horizon Overview
DNS split-horizon routes resolution requests for different domains to distinct DNS servers, greatly improving network access. A well-designed setup can:
- Accelerate domain resolution
- Increase website stability
- Optimize cross-border access
- Avoid DNS pollution
NullPrivate Split-Horizon Configuration
Basic Example
# Domestic DNS servers
223.5.5.5 # Alibaba DNS
2400:3200::1 # Alibaba DNS IPv6
public0.adguardprivate.svc.cluster.local # Private DNS, mainland upstream
# Overseas DNS servers
tls://1.0.0.1 # Cloudflare DNS
tls://[2606:4700:4700::1001] # Cloudflare DNS IPv6
public2.adguardprivate.svc.cluster.local # Private DNS, other upstream
# Split-horizon rules
[/google.com/bing.com/github.com/stackoverflow.com/]tls://1.0.0.1 public2.adguardprivate.svc.cluster.local
[/cn/xhscdn.com/tencentclb.com/tencent-cloud.net/aliyun.com/alicdn.com/]223.5.5.5 2400:3200::1 public0.adguardprivate.svc.cluster.local
Domestic Carrier DNS Servers
China Telecom DNS Servers
Name | Primary DNS Server | Secondary DNS Server |
---|---|---|
Anhui CT | 61.132.163.68 | 202.102.213.68 |
Beijing CT | 219.142.76.3 | 219.141.140.10 |
Chongqing CT | 61.128.192.68 | 61.128.128.68 |
Fujian CT | 218.85.152.99 | 218.85.157.99 |
Gansu CT | 202.100.64.68 | 61.178.0.93 |
Guangdong CT | 202.96.128.86 | 202.96.128.166 |
Guangxi CT | 202.103.225.68 | 202.103.224.68 |
Guizhou CT | 202.98.192.67 | 202.98.198.167 |
Henan CT | 222.88.88.88 | 222.85.85.85 |
Heilongjiang CT | 219.147.198.230 | 219.147.198.242 |
Hubei CT | 202.103.24.68 | 202.103.0.68 |
Hunan CT | 222.246.129.80 | 59.51.78.211 |
Jiangsu CT | 218.2.2.2 | 218.4.4.4 |
Jiangxi CT | 202.101.224.69 | 202.101.226.68 |
Inner Mongolia CT | 219.148.162.31 | 222.74.39.50 |
Shandong CT | 219.146.1.66 | 219.147.1.66 |
Shaanxi CT | 218.30.19.40 | 61.134.1.4 |
Shanghai CT | 202.96.209.133 | 116.228.111.118 |
Sichuan CT | 61.139.2.69 | 218.6.200.139 |
Tianjin CT | 219.150.32.132 | 219.146.0.132 |
Yunnan CT | 222.172.200.68 | 61.166.150.123 |
Zhejiang CT | 202.101.172.35 | 61.153.177.196 |
Tibet CT | 202.98.224.68 | 202.98.224.69 |
China Unicom DNS Servers
Name | Primary DNS Server | Secondary DNS Server |
---|---|---|
Beijing CU | 123.123.123.123 | 123.123.123.124 |
Chongqing CU | 221.5.203.98 | 221.7.92.98 |
Guangdong CU | 210.21.196.6 | 221.5.88.88 |
Hebei CU | 202.99.160.68 | 202.99.166.4 |
Henan CU | 202.102.224.68 | 202.102.227.68 |
Heilongjiang CU | 202.97.224.69 | 202.97.224.68 |
Jilin CU | 202.98.0.68 | 202.98.5.68 |
Jiangsu CU | 221.6.4.66 | 221.6.4.67 |
Inner Mongolia CU | 202.99.224.68 | 202.99.224.8 |
Shandong CU | 202.102.128.68 | 202.102.152.3 |
Shanxi CU | 202.99.192.66 | 202.99.192.68 |
Shaanxi CU | 221.11.1.67 | 221.11.1.68 |
Shanghai CU | 210.22.70.3 | 210.22.84.3 |
Sichuan CU | 119.6.6.6 | 124.161.87.155 |
Tianjin CU | 202.99.104.68 | 202.99.96.68 |
Zhejiang CU | 221.12.1.227 | 221.12.33.227 |
Liaoning CU | 202.96.69.38 | 202.96.64.68 |
China Mobile DNS IPs
Name | Primary DNS Server | Secondary DNS Server |
---|---|---|
Beijing CM | 221.130.33.60 | 221.130.33.52 |
Guangdong CM | 211.136.192.6 | 211.139.136.68 |
Jiangsu CM | 221.131.143.69 | 112.4.0.55 |
Anhui CM | 211.138.180.2 | 211.138.180.3 |
Shandong CM | 218.201.96.130 | 211.137.191.26 |
Public DNS IPs
Name | Primary DNS Server | Secondary DNS Server |
---|---|---|
114 DNS | 114.114.114.114 | 114.114.115.115 |
CNNIC SDNS | 1.2.4.8 | 210.2.4.8 |
Alibaba Public | 223.5.5.5 | 223.6.6.6 |
DNSPod DNS+ | 119.29.29.29 | 119.29.29.29 |
Google DNS | 8.8.8.8 | 8.8.4.4 |
Configuration Tips
- Prefer geographically close DNS servers
- Configure both IPv4 and IPv6 DNS
- Set up backup DNS for critical domains
- Update split-horizon rules regularly
- Monitor DNS response times
Precautions
- Record original DNS settings before changes
- Avoid untrusted DNS servers
- Periodically verify DNS resolution
- Keep rule lists concise and effective
Proper DNS split-horizon configuration can significantly improve network access. Choose DNS servers and rules according to your actual needs.
References
5 - Using Custom Device Names
If you use the service’s listening address directly, such as:
tls://xxxxxxxx.adguardprivate.com
https://xxxxxxxx.adguardprivate.com/dns-query
the IP shown in the dashboard under Client Rankings will be the cluster IP of the load balancer, which is meaningless to you and prevents differentiating individual devices.
You can identify different devices by extending the hostname or adding a URL path.
- DoT uses the extended-hostname method, e.g.
tls://device1.xxxxxxxx.adguardprivate.com
- DoH uses the additional-path method, e.g.
https://xxxxxxxx.adguardprivate.com/dns-query/device2
Notes:
- On Android, you do not need the protocol prefix
tls://
; simply enterdevice1.xxxxxxxx.adguardprivate.com
- On Apple devices, follow the setup guide: enter the client ID, download the configuration profile, and you’re done—no manual entry required.
All devices on a personal service share the service’s query limit of 30 requests per second.
6 - Faster Request Response
Paid users utilize the NullPrivate private service; the DNS request path is as follows:
Based on this path, we can analyze the fastest response strategy.
Local Cache Hit
The fastest response is a local cache hit. Because the local cache operates at the memory level, it is extremely fast—only a few microseconds.
This is controlled by the TTL (time to live) value in the DNS response, typically ranging from minutes to hours, indicating that the query result remains valid during this period and does not need to be queried again.
You can set the minimum TTL value in Control Panel -> Settings -> DNS Settings -> DNS Cache Configuration -> Override Minimum TTL
. Increasing this value extends cache duration, allowing the system to use the local cache more frequently. A common TTL value is 600 seconds.
However, since this site also provides filtering capabilities, if a service you need is mistakenly blocked by ad rules, you won’t be able to access it immediately even after temporarily disabling encrypted DNS, because the local cache result has been modified by the filtering rules. Therefore, setting it to 60 seconds is a safer value, ensuring that in rare cases users won’t have to wait too long after disabling encrypted DNS due to false blocks.
NullPrivate DNS Server
Currently, the site uses Alibaba Cloud servers located in Hangzhou, which can meet the low-latency needs of most users in the eastern region. As the business grows, more servers will be added nationwide in the future.
Server Cache Hit
By default, each user is allocated 4 MB of DNS cache. Based on experience, this is sufficient for a household. Allowing users to freely modify this setting may result in forced service termination, so the modification entry for this setting has been disabled.
Upstream DNS Server
Since Alibaba Cloud services are used, upstream DNS services also use Alibaba Cloud DNS, which is very fast, typically returning results within a few milliseconds.
Users have three ways to request upstream DNS servers:
- Load Balancing: Load balancing is enabled by default, automatically selecting the fastest server to return results.
- Parallel Requests: The site does not restrict the use of parallel requests.
- Fastest IP Address: Currently a meaningless setting; the modification entry for this setting has been disabled.
Here’s why the “fastest IP address” is meaningless: the fastest IP must be chosen by the actual device accessing the service. When NullPrivate runs in Hangzhou but the user is in Beijing, NullPrivate considers Hangzhou’s IP address the fastest, but in reality, the user accessing a Beijing service is fastest; choosing Hangzhou’s IP address actually increases latency. Therefore, the modification entry for this setting has been disabled. This setting might be useful in a user’s home network but is meaningless in a public service.
Many factors affect network experience, such as server-side bandwidth, network congestion, server load, and network quality. Choosing the fastest IP address does not guarantee the fastest response speed; latency is only one factor, not the sole factor. To prevent users from misconfiguring and degrading service quality, the modification entry for this setting has been disabled.
Rule Filtering
The most commonly used mode is the blacklist list, where users can choose from preset blacklist lists. Blacklist hits use a hash algorithm; regardless of the number of rules, hit time is O(1), so users need not worry about excessive rule volume causing long hit times.
However, rules are calculated and stored in memory. Each user’s service memory usage is limited to 300 MB, which meets the needs of most users. If a user’s rule volume is too large, it may cause insufficient memory, leading to repeated service restarts and service interruption.
Currently, the site has disabled third-party rules to prevent users from introducing excessive rules. Once better restriction methods are available, third-party rules will be reopened.
Summary
To achieve faster request response, users can:
- Appropriately increase the minimum TTL value to improve local cache hit rate.
- Set an appropriate DNS cache size (preset value).
- Choose the geographically closest city to create a service (pending business expansion).
- If no overseas access is needed, use load balancing; if overseas access is needed, use parallel requests.
- Use blacklist rules suitable for yourself, avoiding introducing excessive rules.
7 - Set Up Trusted Upstream Providers
When a paid service is created, it defaults to domestic upstream servers that are relatively fast, including Alibaba’s IPv4 and IPv6 as well as DoT services.
Some providers may have resolution errors, resolving certain overseas domains to incorrect IP addresses and causing access failures. A common symptom is the browser reporting a certificate error.
To avoid such resolution errors, you can switch upstream providers and use Cloudflare’s services. When using these services, make sure to adopt DoH or DoT protocols to prevent hijacking.
At the same time, you should disable domestic upstream servers because they are geographically closer and faster, and AdGuard will prefer them.
Simply prepend a #
to the IP of the corresponding upstream server to disable it.
After configuration, click Test upstreams to ensure the upstream servers are available, then click Apply once confirmed.
However, using only overseas servers will degrade the experience of domestic apps, because domestic apps usually direct overseas resolutions to specific external servers, which are slower when accessed from within China.
If you only need to avoid resolution errors for commonly used services, you can manually specify a particular resolution address for domains that are incorrectly resolved; unspecified domains will continue to use the default domestic upstream servers.
In the AdGuard dashboard, go to Settings → DNS settings → Upstream DNS servers, add incorrectly resolved domains in the format [/example1.com/example2.com/]tls://1.0.0.1
under Custom DNS servers, then click Save configuration.
public2.adguardprivate.svc.cluster.local
is our internally provided resolver without resolution errors, whose upstream is Cloudflare. Compared to users specifying an overseas upstream themselves, it offers faster resolution speeds at the cost of a small delay when domain records are updated. If you have no specialized requirements, you can use this resolver we provide.
If you prefer to use external resolvers such as Cloudflare or Google, you need to specify IP addresses using DoT/DoH. You can refer to the following:
#tls://1.1.1.1
tls://1.0.0.1
tls://[2606:4700:4700::1111]
tls://[2606:4700:4700::1001]
tls://[2606:4700:4700::64]
tls://[2606:4700:4700::6400]
https://1.1.1.1/dns-query
https://1.0.0.1/dns-query
https://[2606:4700:4700::1111]/dns-query
https://[2606:4700:4700::1001]/dns-query
#tls://8.8.8.8
#tls://8.8.4.4
tls://[2001:4860:4860::8888]
tls://[2001:4860:4860::8844]
tls://[2001:4860:4860::64]
tls://[2001:4860:4860::6464]
#https://8.8.8.8/dns-query
#https://8.8.4.4/dns-query
#https://[2001:4860:4860::8888]/dns-query
https://[2001:4860:4860::8844]/dns-query
Addresses commented with
#
are currently blocked by the firewall and unavailable.
This site fully supports IPv6, which is one of our advantages. You can use IPv6 upstream addresses for more stable resolution speeds.