Blog - NullPrivate Tech Sharing & Product Updates

• NingPing Ad-Block: DNS-Based Intelligent Ad-Filtering Solution
• Technical Comparison of DoH vs DoT
• DNS Privacy Protection and User Profiling Mitigation Strategies
• Deep Dive: NullPrivate DNS Proxy – Bypass Restrictions and Safeguard Privacy
• Rebranding Announcement for AdGuardPrivate
• Added DDNS Feature
• Better ECS Support
• NullPrivate - Enhanced DNS Service Based on AdGuard Home
• Full Support for HTTP/3 Protocol
• Introducing Custom Client Name Feature
• The Necessity of Ad Blocking: Safeguarding Attention and Privacy in the Digital Age
• Service Resource Optimization Strategy Guide
• Basic Memory Limit Adjustment
• Always Here to Support You
• How to Set Up a Dedicated Link
• All-new Upgrade – Enhanced Ad-blocking Rules
• Trial Service Details

NingPing Ad-Block: DNS-Based Intelligent Ad-Filtering Solution

In today’s digital era, advertising has become an integral part of the internet ecosystem, yet excessive ads not only degrade user experience but also pose privacy risks. NingPing (NullPrivate), a DNS service focused on privacy protection, adopts DNS-filtering technology similar to AdGuard Home to provide users with an effective ad-blocking solution.

How NingPing Ad-Block Works

NingPing’s ad-blocking relies on DNS (Domain Name System) filtering. The workflow is as follows:

flowchart TB
    A[User Device] --> B{DNS Query}
    B --> C[NingPing DNS Server]
    C --> D[Query Domain Database]
    D --> E{Ad or Tracker Domain?}
    E -->|Yes| F[Return Null or Loopback]
    E -->|No| G[Return Correct IP]
    F --> H[Block Ad Load]
    G --> I[Normal Site Access]

DNS Request Monitoring

When your device tries to visit a website, it first queries the DNS server for the domain’s IP address. Acting as your primary DNS server, NingPing receives and analyzes these queries.

Intelligent Filtering

NingPing maintains a large database of advertising and tracking domains. When it detects a request for such a domain, the system blocks it immediately.

Efficient Response

For blocked requests, NingPing returns a null address or the local loopback address (e.g., 127.0.0.1), preventing ad content from loading. For legitimate requests, NingPing supplies the correct IP so users can access the intended site normally.

Technical Advantages

Efficiency

• Network-level blocking: Ads are stopped at the DNS-resolution stage, before any web content is downloaded.
• Millisecond-level response: Localized DNS responses add virtually no latency.
• Whole-network protection: One configuration shields every device on the network.

Precision

• Multi-layer filtering: Supports exact domain matching, wildcard rules, and regular expressions.
• Smart categorization: Rules are grouped by ads, trackers, malware, etc.
• Dynamic updates: Regularly pulls the latest rules from trusted sources.

Privacy Protection

• No-trace browsing: No user-visit logs are kept.
• Reduced data leakage: Prevents advertisers and trackers from harvesting user data.
• Local processing: Most filtering occurs locally, minimizing data exposure.

Similarities to AdGuard Home

NingPing and AdGuard Home share the same core ad-blocking principles:

1. DNS-based filtering: Both intercept DNS queries to block ad domains.
2. Rule management: Both allow custom rules and whitelist/blacklist configuration.
3. Network-wide protection: Both can safeguard an entire LAN.
4. Open-source community: Both benefit from community-maintained filter lists.

User-Experience Optimizations

NingPing is designed to block ads effectively without disrupting normal use.

Transparent Management

• Detailed blocking statistics let users see protection effectiveness.
• Flexible whitelist settings prevent accidental blocking of important sites.
• Rule updates take effect instantly—no device restart required.

Ease of Use

• Simplified setup process—accessible even for non-technical users.
• Multi-language support for global audiences.
• Compatible with all network environments and device types.
• Secure, reliable DNS infrastructure.

Privacy Safeguards

• Strict privacy measures protect user data.
• No personally identifiable information is collected.
• User data remains secure.

Usage Recommendations

For optimal ad-blocking:

1. Configure rules wisely: Choose filter lists that match your needs.
2. Check for updates regularly: Keep rule databases current.
3. Review statistics: Use stats to gauge blocking effectiveness.
4. Adjust whitelists promptly: Add mistakenly blocked sites to the whitelist.

Conclusion

Using advanced DNS filtering, NingPing delivers an efficient, precise, and privacy-centric ad-blocking solution. We protect users from intrusive ads while preserving normal web experiences. Choose NingPing for a cleaner, safer internet.

In the digital age, everyone deserves a private, uncluttered online space. NingPing is built to deliver exactly that, helping users reclaim control of their digital lives.

Technical Comparison of DoH vs DoT

DNS over HTTPS (DoH) and DNS over TLS (DoT) are two common encrypted DNS transmission methods that implement secure DNS queries through different protocol stacks. DoT is standardized by RFC 7858, while DoH is standardized by DNS Queries over HTTPS (DoH). To understand the fundamental differences between these two technologies, we must analyze them from the perspective of network protocol hierarchy.

Network Protocol Hierarchy

Modern network protocol stacks adopt a layered design, with each layer providing distinct functionalities. DNS, as an application-layer protocol, isn’t bound to any specific transport method and can operate over various carrier protocols.

The Application Layer (L7) includes protocols like HTTP/1.1, HTTP/2, HTTP/3, FTP, and DNS. Notably, HTTP/3’s semantics remain at the application layer, though QUIC serves as its transport carrier. The Security Layer sits between the application and transport layers, primarily consisting of TLS and its variants. TLS typically runs over TCP, as seen in HTTPS and DoT. DTLS is the datagram version of TLS that can operate over UDP. The QUIC protocol is special as it integrates TLS 1.3 handshakes and key derivation directly within the protocol.

QUIC can be considered an L4.5 protocol. Based on UDP extensions, it provides traditional transport-layer capabilities. The Transport Layer (L4) includes TCP, UDP, and QUIC. Although QUIC is implemented over UDP from an engineering perspective, it incorporates reliability, congestion control, multiplexing, and encrypted handshake features, making it effectively an independent transport-layer protocol in practice. The Network Layer (L3) uses IP protocols (IPv4/IPv6) for packet routing and forwarding. The Data Link Layer (L2) includes technologies like Ethernet and Wi-Fi (802.11).

TLS operates between the application and transport layers as an encryption mechanism. If TLS encryption were removed from DoT, DoT would essentially become DNS over TCP. This layered design makes encryption optional rather than a mandatory protocol constraint.

Characteristics of Plain DNS

The most basic DNS implementation is called Plain DNS, which can operate over UDP or TCP. UDP is the most common carrier due to its simple connection setup and faster initial query speed. However, UDP’s weakness is unreliability, as packets can be easily lost in transit. Although TCP requires more handshakes (making initial connections about 30% slower than UDP), its response speed matches UDP once a persistent connection is established.

Network operators may discard UDP packets to alleviate device pressure during network congestion. In regions where certain operators experience severe UDP packet loss, specifying TCP for DNS queries might be more advantageous. TCP’s retransmission mechanism ensures reliable data delivery even with packet loss, whereas UDP packet loss doesn’t reduce load pressure on smaller operators’ equipment and may introduce more uncertainty through retries.

Application Layer Nesting

Both DNS and HTTP are application-layer protocols. DoH essentially nests one application-layer protocol within another. DoH doesn’t necessarily mean DNS over HTTPS - using plain HTTP is possible, but unencrypted DoH offers no advantages over Plain DNS since it’s cleartext. Only a few specialized scenarios would use this approach.

Theoretically, DNS can be carried over any application-layer protocol. For example, DNS over FTP could also be implemented by developing corresponding server and client components. This flexibility demonstrates the combinatorial possibilities of application-layer protocols.

flowchart TD
    subgraph L7["Application Layer"]
        A[DNS]
        B[HTTP]
        C[FTP]
    end
    
    subgraph Security["Security Layer"]
        D[TLS]
        E[DTLS]
    end
    
    subgraph Transport["Transport Layer"]
        F[TCP]
        G[UDP]
        H[QUIC]
    end
    
    subgraph L3["Network Layer"]
        I[IP]
    end
    
    subgraph L2["Data Link Layer"]
        J[Ethernet]
        K[WiFi]
    end
    
    A --> D
    B --> D
    C --> D
    D --> F
    E --> G
    H --> G
    F --> I
    G --> I
    H --> I
    I --> J
    I --> K
    
    style A fill:#e1f5ff
    style B fill:#e1f5ff
    style C fill:#e1f5ff
    style D fill:#fff4e1
    style E fill:#fff4e1
    style F fill:#ffe1e1
    style G fill:#ffe1e1
    style H fill:#e1ffe1

Transport Layer Nesting

The QUIC protocol is based on UDP while providing connection-oriented services at the transport layer. QUIC implements transport-layer capabilities already present in TCP, including connection orientation, congestion control, retransmission, flow control, fragmentation, and reassembly. Compared to TCP, QUIC has lower latency. Compared to UDP, QUIC is more advanced and reliable.

Protocol Combination Relationships

There are no inherent restrictions between application and transport layers - encryption can be added or omitted. HTTP can run over TCP or QUIC. DNS can run over TCP, UDP, or QUIC.

Based on these possibilities, we can summarize the following combinations:

• Plain DNS = UDP or TCP + DNS protocol
• HTTP/2 = TCP + TLS 1.2/1.3 + HTTP protocol
• HTTP/3 = QUIC + TLS 1.3 + HTTP protocol
• DoH (DNS over HTTPS) = HTTP/2 or HTTP/3 + DNS protocol
• DoT (DNS over TLS) = TCP + TLS 1.2/1.3 + DNS protocol
• DoQ (DNS over QUIC) = QUIC + TLS 1.3 + DNS protocol

flowchart LR
    subgraph DoT["DoT DNS over TLS"]
        direction LR
        T1[TCP] --> T2[TLS]
        T2 --> T3[DNS]
    end
    
    subgraph DoH2["DoH over HTTP/2"]
        direction LR
        H1[TCP] --> H2[TLS]
        H2 --> H3[HTTP/2]
        H3 --> H4[DNS]
    end
    
    subgraph DoH3["DoH over HTTP/3"]
        direction LR
        Q1[QUIC] --> Q2[TLS 1.3]
        Q2 --> Q3[HTTP/3]
        Q3 --> Q4[DNS]
    end
    
    subgraph DoQ["DoQ DNS over QUIC"]
        direction LR
        D1[QUIC] --> D2[TLS 1.3]
        D2 --> D3[DNS]
    end
    
    style T1 fill:#e3f2fd
    style T2 fill:#fff3e0
    style H1 fill:#e3f2fd
    style H2 fill:#fff3e0
    style Q1 fill:#e8f5e9
    style Q2 fill:#fff3e0
    style D1 fill:#e8f5e9
    style D2 fill:#fff3e0

Performance and Compatibility Analysis

Understanding the protocol hierarchy allows us to analyze the pros and cons of DoH and DoT.

Comparing TCP and QUIC requires considering actual network operator environments. QUIC is a newer protocol that solves some legacy network issues, but it’s fundamentally UDP-based. From a latency perspective, QUIC-based protocols show about 35% lower latency than TCP-based ones, making DNS over HTTP/3 and DoQ (DNS over QUIC) theoretically better performing than DNS over HTTP/2 and DoT.

However, real-world networks face retransmission delays caused by packet loss. Operators may discard UDP packets during network congestion, and QUIC traffic identified as UDP might be dropped. Although QUIC supports retransmission, the resulting delays could make QUIC’s actual latency higher than TCP in such scenarios.

Regarding privacy and security, both DoH and DoT use encrypted traffic that can’t be intercepted or tampered with. The concern about DoT being blocked after identification mainly stems from Android’s encrypted DNS settings defaulting to port 853, making it a sensitive port. DoT itself is ordinary encrypted traffic and isn’t specifically identified as DNS traffic. In reality, any port can provide DoT services, though this requires third-party apps on Android while iOS natively supports DoT on arbitrary ports.

DoH has a significant advantage in extensibility. Compared to HTTP-encapsulated DNS and Plain DNS, HTTP offers clearly superior extensibility. Service providers can offer numerous services on port 443, including DoH, while easily expanding functionality. DoT and DoQ typically require dedicated ports, with expansion capabilities limited to Plain DNS features. This represents a service provider perspective difference, though ordinary users might not currently perceive it noticeably.

Regarding DNS request processing speed, HTTP might indeed be a few CPU clock cycles slower than Plain DNS, but this difference is negligible in practical use. In terms of compatibility, DoH might become more mainstream due to its better extensibility for service providers.

Current mainstream platform support for encrypted DNS varies:

• Chromium-based browsers support DoH
• Windows 11 natively supports DoH
• Android 8+ natively supports DoT
• Android 11+ natively supports both DoT and DoH
• macOS natively supports both DoT and DoH
• iOS natively supports both DoT and DoH

Practical Selection Recommendations

For ordinary users, using DoH might be more convenient than DoT. Compared to DoT, DoH generally offers better latency most of the time and similar latency occasionally. Compared to DoQ, DoH shows similar latency most of the time and better latency occasionally.

This conclusion assumes the service provider offers DNS over HTTP/3. If not, there’s no significant difference between DoH and DoT. When network quality is good, DoH automatically uses DoH/3 for lower latency, and falls back to HTTP/2 when network quality deteriorates. This adaptive capability requires provider implementation, which most mainstream providers already offer.

We recommend trying NullPrivate, which supports DoT and DoH/3 with native ad-blocking and DNS split tunneling features. For self-deployment, you can use its open-source library.

Protocol selection requires comprehensive consideration of multiple factors including operator network quality, provider support, and device compatibility. For most users, DoH represents an excellent choice that balances performance, compatibility, and privacy protection.

DNS Privacy Protection and User Profiling Mitigation Strategies

DNS Privacy Protection and User Profiling Mitigation Strategies

Audience: Engineers/Operators/Security Professionals concerned with network privacy and data governance
Keywords: Stub resolver, Recursive resolution, Authoritative server, QNAME minimization, ECS, DNSSEC, DoT/DoH/DoQ

Background and Problem Overview

In the digital age, users’ online behavioral data has become crucial for enterprises to construct user profiles. As a core component of internet infrastructure, the Domain Name System (DNS) performs the critical task of converting human-readable domain names into machine-readable IP addresses during daily network activities. However, traditional DNS queries are typically transmitted in plaintext over UDP port 53, making users’ browsing history, application usage patterns, and other sensitive information vulnerable to collection and analysis by network operators, ISPs, and various intermediaries.

User profiling refers to constructing characteristic models of users through collecting and analyzing various behavioral data. Enterprises leverage these models for precision marketing, content recommendation, risk assessment, and other commercial activities. While these services enhance user experience to some extent, they also raise concerns about privacy leaks, data misuse, and potential discriminatory pricing. Understanding how to reduce the accuracy of user profiling through DNS-level technical measures has become an important approach to protecting personal privacy.

This article begins with DNS fundamentals, analyzes data collection points in user profiling processes, explores DNS-based privacy protection strategies, and explains implementation approaches and considerations for different scenarios.

Fundamentals and Terminology

To understand DNS privacy protection, one must first grasp the basic DNS query workflow and related terminology. DNS queries typically involve multiple participants, each potentially becoming a privacy leakage point.

flowchart LR
    A[Client Device] e1@--> B[Stub Resolver]
    B e2@--> C[Recursive Resolver]
    C e3@--> D[Root Server]
    D e4@--> E[TLD Server]
    E e5@--> F[Authoritative Server]
    F e6@--> C
    C e7@--> B
    B e8@--> A
    C --> G[Cache Storage]
    
    e1@{ animation: fast }
    e2@{ animation: slow }
    e3@{ animation: medium }
    e4@{ animation: fast }
    e5@{ animation: medium }
    e6@{ animation: fast }
    e7@{ animation: fast }
    e8@{ animation: slow }
    
    style A fill:#e1f5fe
    style B fill:#f3e5f5
    style C fill:#fff3e0
    style D fill:#f1f8e9
    style E fill:#f1f8e9
    style F fill:#f1f8e9
    style G fill:#fce4ec

The stub resolver is the DNS client component in operating systems or applications, responsible for receiving DNS query requests from applications and forwarding them to recursive resolvers. Recursive resolvers (typically provided by ISPs or third-party DNS services) complete the full domain resolution process, including querying root servers, Top-Level Domain (TLD) servers, and authoritative servers, then returning final results to clients.

Authoritative servers store DNS records for specific domains and serve as the ultimate source of domain information. Caching mechanisms are essential components of the DNS system, where recursive resolvers cache query results to reduce duplicate queries and improve resolution efficiency. TTL (Time To Live) values determine how long DNS records remain cached.

EDNS Client Subnet (ECS) is an extension mechanism that allows recursive resolvers to transmit client subnet information to authoritative servers, aiming to improve CDN and geolocation service accuracy. However, ECS also exposes users’ geographical location information, increasing privacy leakage risks.

Privacy Threats and Motivations

Plaintext DNS queries provide rich data sources for user profiling construction. By analyzing DNS query logs, attackers or data collectors can obtain sensitive information including users’ browsing habits, application usage patterns, and geographical locations, enabling the construction of detailed user profiles.

flowchart TD
    A[User Online Behavior] e1@--> B[Plaintext DNS Queries]
    B e2@--> C[ISP Resolver]
    B e3@--> D[Public DNS Service]
    C e4@--> E[User Access Records]
    D e5@--> F[Query Logs]
    E e6@--> G[Behavior Analysis]
    F e7@--> G
    G e8@--> H[User Profile]
    H e9@--> I[Precision Advertising]
    H e10@--> J[Content Recommendation]
    H e11@--> K[Price Discrimination]
    
    L[Third-party Trackers] e12@--> M[Cross-site Correlation]
    M e13@--> G
    
    N[Device Fingerprint] e14@--> O[Unique Identifier]
    O e15@--> G
    
    e1@{ animation: fast }
    e2@{ animation: medium }
    e3@{ animation: medium }
    e4@{ animation: slow }
    e5@{ animation: slow }
    e6@{ animation: fast }
    e7@{ animation: fast }
    e8@{ animation: medium }
    e9@{ animation: fast }
    e10@{ animation: fast }
    e11@{ animation: fast }
    e12@{ animation: medium }
    e13@{ animation: fast }
    e14@{ animation: medium }
    e15@{ animation: fast }
    
    style A fill:#e1f5fe
    style B fill:#fff3e0
    style C fill:#ffebee
    style D fill:#ffebee
    style E fill:#fce4ec
    style F fill:#fce4ec
    style G fill:#f3e5f5
    style H fill:#e8eaf6
    style I fill:#fff9c4
    style J fill:#fff9c4
    style K fill:#ffcdd2
    style L fill:#ffebee
    style M fill:#fce4ec
    style N fill:#ffebee
    style O fill:#fce4ec

DNS query data provides value for user profiling construction in several aspects. First, query frequency and temporal patterns can reveal users’ daily routines, such as differences between weekday and weekend internet habits, or nighttime activity patterns. Second, queried domain types can reflect user interests, such as preferences for news websites, social media, video platforms, or shopping sites. Additionally, subdomain access patterns can provide granular behavioral analysis, such as whether users frequently access specific sub-feature pages of social platforms.

Geolocation information is a crucial component of user profiles. Through ECS mechanisms and analysis of recursive resolver locations, users’ physical locations or movement trajectories can be inferred. Combined with time-series analysis, frequently visited locations and activity ranges can be identified.

Cross-device identity correlation is another key aspect of user profiling. By analyzing specific patterns in DNS queries—such as query timing distributions for the same domain across different devices—multiple devices belonging to the same user can potentially be correlated to build more comprehensive profiles.

Commercial motivations drive user profiling construction. Precision advertising is the primary application, where enterprises analyze users’ browsing interests to display more relevant ads, improving conversion rates. Content recommendation systems leverage user profiles to provide personalized news, videos, and product suggestions, enhancing user engagement. Risk assessment applies to financial and insurance sectors, evaluating credit risks or fraud probabilities based on user behavior patterns.

Protection Strategies and Principles

To address DNS privacy leakage risks, the industry has developed multiple protection strategies focusing on three main directions: encrypted transmission, query obfuscation, and source control. These strategies each have distinct characteristics suitable for different scenarios and requirements.

flowchart TD
    A[DNS Privacy Strategies] --> B[Encrypted Transport]
    A --> C[Query Obfuscation]
    A --> D[Source Control]
    
    B --> B1[DoT - DNS over TLS]
    B --> B2[DoH - DNS over HTTPS]
    B --> B3[DoQ - DNS over QUIC]
    
    C --> C1[QNAME Minimization]
    C --> C2[Batch Queries]
    C --> C3[Timing Randomization]
    
    C1 --> C1A[Step-wise Transmission]
    C1 --> C1B[Reduced Exposure]
    
    D --> D1[Local Hosts]
    D --> D2[Trusted Recursive Resolvers]
    D --> D3[DNS Filtering]
    
    D2 --> D2A[Privacy Policy]
    D2 --> D2B[No-logging]
    D2 --> D2C[Third-party Audits]
    
    style A fill:#e1f5fe
    style B fill:#e8f5e8
    style C fill:#fff3e0
    style D fill:#f3e5f5
    style B1 fill:#e8f5e8
    style B2 fill:#e8f5e8
    style B3 fill:#e8f5e8
    style C1 fill:#fff3e0
    style C2 fill:#fff3e0
    style C3 fill:#fff3e0
    style D1 fill:#f3e5f5
    style D2 fill:#f3e5f5
    style D3 fill:#f3e5f5

Encrypted transport forms the foundation of DNS privacy protection, primarily comprising three technologies: DNS over TLS (DoT), DNS over HTTPS (DoH), and DNS over QUIC (DoQ). DoT uses TCP port 853 to transmit encrypted DNS queries, providing end-to-end encryption through TLS. DoH encapsulates DNS queries within HTTPS traffic using standard port 443, better integrating with existing network environments and avoiding identification/blocking by firewalls or network management devices. DoQ is an emerging solution based on the QUIC protocol, combining UDP’s low latency with TLS security while supporting advanced features like connection migration.

QNAME minimization (RFC7816) is a query obfuscation technique where recursive resolvers incrementally send domain components to upstream servers rather than complete domain names. For example, when querying “www.example.com”, it first queries “com”, then “example.com”, and finally “www.example.com”. This approach reduces complete domain exposure to upstream servers but may increase query latency.

Batch queries and timing randomization are additional obfuscation methods. Batch queries distribute multiple DNS requests across different times to prevent behavioral correlation through query patterns. Timing randomization introduces random delays between queries to disrupt temporal pattern analysis.

Source control strategies focus on DNS query origination points. Local hosts files can bypass DNS queries for frequently accessed domains, reducing query records. Trusted recursive resolver selection involves choosing DNS providers with strict privacy policies, such as those committing to no query logging and rejecting third-party tracking. DNS filtering blocks known trackers and malicious domains to minimize unnecessary data exposure.

Implementation Paths and Considerations

Implementing DNS privacy protection requires balancing technical feasibility, performance impact, and deployment complexity. When selecting and implementing specific solutions, trade-offs between privacy protection effectiveness and practical usability must be carefully considered.

Encrypted DNS deployment can adopt multiple approaches. Operating system-level support represents the ideal scenario, with Android 9+, iOS 14+, and Windows 11 all featuring built-in DoH or DoT support. Application-level implementation suits specific software, such as browsers with built-in encrypted DNS functionality. Network device-level deployment configures encrypted DNS on routers or firewalls to protect entire networks.

QNAME minimization implementation primarily relies on recursive resolvers, requiring users to select DNS services supporting this feature. Note that QNAME minimization may impact certain performance optimizations relying on complete domain information, such as prefetching and load balancing.

Selecting trusted recursive resolvers involves evaluating multiple factors. Privacy policies are paramount, including whether query logs are recorded, log retention periods, and data sharing policies. Service performance affects user experience through resolution latency, availability, and global distribution. Service transparency is also crucial, such as whether operational policies are publicly disclosed and undergo third-party audits.

DNS filtering requires attention to false positives and negatives. Overly aggressive filtering may block legitimate websites, while overly lenient filtering fails to adequately protect privacy. Regular filter list updates and customizable allowlists provide necessary balancing measures.

Hybrid strategies can deliver better privacy protection. For example, combining encrypted DNS with QNAME minimization while using DNS filtering to block trackers. However, excessive privacy measures may impact network performance and compatibility, necessitating adjustments based on actual requirements.

Risks and Migration

Deploying DNS privacy protections may encounter various risks and challenges, requiring corresponding migration strategies and contingency plans.

Compatibility risks constitute primary considerations. Encrypted DNS might be blocked in certain network environments, particularly enterprise networks or strictly regulated regions. Fallback mechanisms are critical—when encrypted DNS becomes unavailable, systems should gracefully revert to traditional DNS while minimizing privacy leakage.

Performance impacts require careful evaluation. Encrypted DNS may increase query latency, especially during initial connection handshakes. Cache optimization and connection reuse can mitigate some performance issues. When selecting encrypted DNS services, consider network latency and response times, avoiding geographically distant servers.

Compliance requirements are essential considerations for enterprise deployments. Some regions may have data retention or monitoring requirements potentially conflicting with privacy protections. Understanding local regulatory requirements before deployment and finding balance between privacy and compliance is crucial.

Phased rollout strategies effectively reduce risks. First validate solution feasibility in test environments, then gradually expand to small user groups before full deployment. Monitor key metrics like query success rates, latency changes, and error rates for timely configuration adjustments.

User education and training should not be neglected. Many users may not understand DNS privacy importance, requiring clear explanations and configuration guidance. Particularly in enterprise environments, IT departments should explain privacy protection purposes and usage methods to employees.

Scenario-based Recommendations

Different usage scenarios present distinct DNS privacy protection requirements and implementation strategies, necessitating tailored solutions for specific environments.

In home network scenarios, router-level deployment represents an excellent choice. Routers supporting encrypted DNS can protect entire home networks, including IoT devices and smart home products. Selecting family-friendly DNS services—such as those supporting parental controls and malicious site filtering—provides additional security alongside privacy protection.

Mobile work scenarios require special attention to network switching and battery consumption. Choosing DoQ services supporting connection migration improves stability during mobile network transitions. Simultaneously, consider battery optimization strategies to prevent frequent DNS queries and encryption operations from excessive power drain.

Enterprise environments must balance privacy protection with network management needs. Hybrid solutions may be necessary, providing privacy protection for general employee traffic while maintaining visibility into specific business traffic for management and compliance. DNS filtering can integrate with enterprise security policies to block malicious domains and data leakage risks.

High-privacy scenarios—such as journalists, lawyers, and medical professionals—may require multi-layered protections. Combine encrypted DNS with VPNs and Tor for comprehensive privacy. Consider using anonymous recursive resolvers that commit to zero query logging.

Cross-border network scenarios require special attention to censorship and regional restrictions. Some encrypted DNS services may be unavailable in specific regions, necessitating multiple backup solutions. Understand local network environment characteristics to select optimal privacy strategies.

Development and testing environments can experiment with cutting-edge privacy technologies, such as experimental DoQ implementations or custom obfuscation schemes. These controlled environments suit testing new technologies’ impacts and compatibility, accumulating experience for production deployments.

FAQ and References

Common Questions

Q: Does encrypted DNS completely prevent user profiling?
A: Encrypted DNS prevents network-level eavesdropping on DNS query content, but recursive resolvers still see complete query records. Choosing trustworthy providers committing to no logging is essential. Combining with other privacy measures like browser anti-tracking features provides more comprehensive protection.

Q: Does QNAME minimization affect DNS resolution performance?
A: QNAME minimization may increase query latency due to multiple upstream queries. Modern recursive resolvers typically optimize performance through intelligent caching and parallel queries, making actual impacts smaller than expected. For most users, privacy benefits far outweigh minor performance costs.

Q: How to verify DNS privacy protection effectiveness?
A: Specialized testing tools like dnsleaktest.com or dnsprivacy.org can validate whether DNS queries use encrypted channels. Network packet sniffers can also check DNS traffic encryption status. Note these tests only verify technical implementation, not providers’ actual privacy policy compliance.

Q: How to balance privacy protection with management needs in enterprise networks?
A: Enterprises can adopt tiered strategies—providing privacy protection for general internet access while maintaining necessary monitoring capabilities for internal business traffic. Solutions supporting traffic splitting apply different DNS policies based on domains or user groups. Clear privacy policies and employee communication are equally important.

Q: Can encrypted DNS be blocked by network operators?
A: Some network environments may restrict or block encrypted DNS traffic, particularly DoT using non-standard ports. DoH—using standard HTTPS port 443—is typically harder to identify and block. In such cases, consider combining multiple encrypted DNS solutions or using complementary privacy tools like VPNs.

Reference Resources

RFC Documents:

• RFC7858: Specification for DNS over Transport Layer Security (TLS)
• RFC8484: DNS Queries over HTTPS (DoH)
• RFC7816: DNS Query Name Minimisation to Improve Privacy
• RFC9250: DNS over Dedicated QUIC Connections

Tools and Services:

• Cloudflare DNS: 1.1.1.1 (Supports DoH/DoT, privacy commitment)
• Quad9: 9.9.9.9 (Supports DoH/DoT, blocks malicious domains)
• NextDNS: Customizable privacy DNS service
• Stubby: Open-source DoT client

Testing and Validation:

• dnsleaktest.com: DNS leak testing
• dnsprivacy.org: DNS privacy testing tools
• browserleaks.com/dns: Browser DNS configuration detection

Further Reading:

• Comprehensive DNS Privacy Technologies
• Enterprise DNS Security and Privacy Balancing Strategies

This article begins with DNS fundamentals, analyzes privacy risks in user profiling processes, and systematically introduces protection strategies including encrypted transport, query obfuscation, and source control. Practical deployments require selecting appropriate solutions based on specific scenarios and needs, balancing privacy protection, performance impact, and compatibility requirements. DNS privacy protection remains an evolving field—as technologies advance and regulations change, protection strategies must continuously adapt and improve.

Deep Dive: NullPrivate DNS Proxy – Bypass Restrictions and Safeguard Privacy

🌐 DNS Proxy Deep Dive

In today’s complex network landscape, traditional DNS services often hit numerous roadblocks. NullPrivate DNS now fully supports upstream DNS proxying, giving users a more flexible and secure browsing experience.

Why You Need DNS Proxying

In some environments—corporate networks, campus networks, or region-specific setups—direct access to upstream DNS servers can face these issues:

• Network Restrictions: DNS servers like 1.1.1.1 or 8.8.8.8 may be blocked by firewalls
• ISP Interference: Carriers can redirect or poison DNS queries
• Geo-blocking: DNS services in certain regions may be inaccessible
• Privacy Concerns: You may need to hide your real IP behind a proxy

🚀 Core Features

DoH & DoT Proxy Support

Built on AdGuard Home and heavily customized, NullPrivate DNS adds these key capabilities:

1. Smart DNS Split-Horizon

   • Auto-detects network conditions
   • Intelligently chooses direct vs. proxy routes based on rules
   • Supports custom split-horizon config files

2. Full Proxy-Protocol Coverage

   • HTTP proxy (http_proxy)
   • HTTPS proxy (https_proxy)
   • SOCKS5 proxy (socks5)

3. Secure Encrypted Transport

   • DoH (DNS over HTTPS) proxy support
   • DoT (DNS over TLS) proxy support
   • End-to-end encryption for privacy

📋 Step-by-Step Configuration

Environment Variables

Enabling DNS proxying is as simple as setting the right proxy variables in your environment.

Linux / macOS

# Temporary (current shell)
export http_proxy="http://proxy.example.com:8080"
export https_proxy="http://proxy.example.com:8080"
export ALL_PROXY="socks5://[username:password@]proxyhost:port"

# Permanent (add to ~/.bashrc or ~/.zshrc)
echo 'export http_proxy="http://proxy.example.com:8080"' >> ~/.bashrc
echo 'export https_proxy="http://proxy.example.com:8080"' >> ~/.bashrc
echo 'export ALL_PROXY="socks5://[username:password@]proxyhost:port"' >> ~/.bashrc
source ~/.bashrc

Windows

# Command Prompt
set http_proxy=http://proxy.example.com:8080
set https_proxy=http://proxy.example.com:8080

# PowerShell
$env:http_proxy="http://proxy.example.com:8080"
$env:https_proxy="http://proxy.example.com:8080"

Docker Container

version: '3.8'
services:
  nullprivate-dns:
    image: nullprivate/nullprivate:latest
    environment:
      - http_proxy=http://proxy.example.com:8080
      - https_proxy=http://proxy.example.com:8080
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "80:80/tcp"
      - "443:443/tcp"

Advanced Options

Authenticated Proxy

If your proxy requires credentials, use this format:

export http_proxy="http://username:password@proxy.example.com:8080"
export https_proxy="https://username:password@proxy.example.com:8080"

Exclude Specific Domains

Skip the proxy for certain domains via the no_proxy variable:

export no_proxy="localhost,127.0.0.1,.local"

🔧 Real-World Use Cases

Corporate Networks

In enterprise environments where external DNS is firewalled, proxying lets you:

• Bypass corporate firewall restrictions
• Reach blocked DNS services
• Securely access external networks

Campus Networks

Campus networks often impose strict DNS controls; proxying helps you:

• Avoid DNS hijacking or pollution
• Achieve faster resolution times
• Protect student privacy and study data

Home Network Protection

Home users can:

• Conceal the real home IP
• Prevent ISP tracking of browsing habits
• Provide safer internet for children

⚡ Technical Advantages

🛠️ Troubleshooting Guide

Common Issues & Fixes

Q: DNS resolution fails after enabling proxy

Likely causes:

• Proxy unreachable
• Proxy lacks HTTPS support
• Connectivity issues

Solutions:

1. Test proxy: curl -x http://proxy.example.com:8080 https://www.google.com
2. Verify env vars: env | grep proxy
3. Restart NullPrivate service

Q: Proxy connection timeouts

Likely causes:

• Slow proxy response
• High latency
• Overloaded proxy

Solutions:

1. Switch proxy server
2. Adjust DNS timeout settings
3. Load-balance across multiple proxies

Q: Specific domains resolve incorrectly

Likely causes:

• Domain on proxy blacklist
• DNS cache issues
• Misconfigured proxy DNS

Solutions:

1. Flush DNS cache
2. Review proxy config
3. Try direct mode

📊 Performance Monitoring

After proxying is enabled, monitor:

1. DNS query latency – see if resolution speeds improve
2. Success-rate stats – track proxy connection success
3. Traffic analysis – review proxy bandwidth usage
4. Error logs – scan system logs regularly for issues

🔒 Security Best Practices

1. Use trusted proxies – rely on reputable providers
2. Prefer encryption – choose HTTPS proxies when possible
3. Rotate proxies – periodically change servers for added safety
4. Monitor traffic – keep an eye on proxy usage
5. Update configs – refresh settings as networks evolve

🎯 Wrap-up & Roadmap

NullPrivate DNS proxy delivers a flexible, secure way to use DNS in restrictive environments. With minimal configuration, you can bypass limitations and enjoy better privacy.

Coming Next

• SOCKS5 proxy protocol support
• Smart proxy-selection algorithms
• Graphical configuration UI
• Multi-proxy load balancing

🚀 Try It Now

Ready to experience NullPrivate DNS proxy?

1. Visit the GitHub repo
2. Follow the deployment docs
3. Set your proxy environment variables
4. Enjoy a safer, freer internet

Rebranding Announcement for AdGuardPrivate

We recently received a notice from AdGuard stating that “AdGuard” is a registered trademark and may not be used without authorization, even with prefixes or suffixes, as such usage could constitute infringement. To avoid legal risks, our service has been officially renamed “NullPrivate”.

For existing users, your service remains completely unaffected. We will continue to serve you via the adguardprivate.com domain; only the official website and contact information will be migrated.

To prevent new users from mistakenly associating NullPrivate with AdGuard, we hereby clarify: our software product is forked from AdGuardHome and enhanced with new features. All code is open-source and adheres to the same GPLv3 license.

Repository: https://github.com/nullprivate/nullprivate

Users are welcome to review the code and deploy it themselves. Meanwhile, our SaaS version will continue to offer more affordable pricing and more stable service.

Thank you for your ongoing support—may our service keep bringing you value!

Added DDNS Feature

If you already have a NullPrivate service, you can now use the DDNS feature.

Overview

NullPrivate has open-sourced the DDNS script. This dynamic DNS (DDNS) is designed to provide a simple method for quickly setting up private dynamic DNS without purchasing a domain name. This DDNS script was specifically developed for nullprivate.com. By leveraging NullPrivate’s core functionality, you can seamlessly implement this feature.

Usage

1. Ensure NullPrivate is deployed and running.
2. Navigate to DNS Rewrite and download the DDNS script.
3. Run the script.

Windows

Set-ExecutionPolicy Bypass -Scope Process
./ddns-script.ps1

Linux/macOS

chmod +x ddns-script.sh
./ddns-script.sh

Features

• Quick and Easy Setup: Configure in just a few steps.
• DDNS via NullPrivate: Implement DDNS using NullPrivate’s core functionality.
• Multi-Platform Support: Compatible with Windows and Unix-based systems.
• Multiple Authentication Options: Supports authentication via cookies (more secure but may expire) or username/password (more persistent but less secure).

Differences from Traditional DDNS

Compared to traditional DDNS, this private DDNS offers the following advantages:

• No Cache Time: Changes take effect immediately without waiting for DNS cache expiration.
• No DNS Propagation Delay: Updates are instantly available without DNS propagation delays.
• No Domain Purchase Required: Accessible via pseudo-domains without purchasing a domain name.
• Privacy Protection: Only users connected to the private DNS service can resolve DNS, ensuring privacy.

Quick Start Guide

1. Ensure NullPrivate is deployed and running.
2. Follow the instructions in the win/ddns.ps1 (for Windows) or unix/ddns.sh (for Unix-based systems) scripts to configure your private DDNS.

Open Source Repository: https://github.com/NullPrivate/nullprivate-ddns

Better ECS Support

To provide the best DNS resolution experience, we have preset some recommended configurations, but there is still one setting that requires your attention: “EDNS Client Subnet”.

Enable EDNS Client Subnet (ECS)

For an even better experience, you may want the DNS server to return the server IP closest to your geographic location. EDNS Client Subnet (ECS) makes this possible. It allows sending a subnet containing geolocation information to the DNS server so that the server can return the optimal DNS resolution result.

How it works:

When ECS is enabled, your DNS resolver (e.g., AdGuard Home) includes a portion of the client IP address (usually the first 24 bits, representing the subnet where the client is located) in the DNS query and sends it to the upstream DNS server. The upstream DNS server then returns the server IP address most suitable for that region based on this subnet information.

sequenceDiagram
    participant Client
    participant DNS Resolver
    participant Upstream DNS Server

    Client->>DNS Resolver: DNS Query
    DNS Resolver->>Upstream DNS Server: DNS Query with ECS (Client Subnet)
    Upstream DNS Server->>DNS Resolver: DNS Response (Geo-localized IP)
    DNS Resolver->>Client: DNS Response (Geo-localized IP)

Privacy considerations:

Enabling ECS can improve DNS resolution accuracy and speed, but it may also have privacy implications. By sharing the subnet of your client IP address, your approximate geographic location may be recorded by the upstream DNS server. Please weigh whether to enable this feature based on your own circumstances.

How to weigh:

Enabling ECS can balance access speed and accuracy. If you have high privacy requirements, you can choose to disable ECS, but this may reduce access speed. If you want the best access experience, you can enable ECS, but please be aware of the potential privacy impact. This privacy information is collected by the upstream DNS; this service still adheres to the privacy policy commitment of not collecting or utilizing any information.

NullPrivate - Enhanced DNS Service Based on AdGuard Home

NullPrivate: Privacy-First DNS Service

Visit the official site to learn more: NullPrivate

This project is a secondary development based on AdGuard Home and follows the GPL 3.0 open-source license.

Source code is open at: GitHub - NullPrivate/NullPrivate

Enhanced Features

Compared to the original AdGuard Home, we have added the following capabilities:

• 📜 Automated SSL Certificate Management
  • Automatic certificate issuance and renewal
  • Support for wildcard certificate configuration
• 🛡️ Enhanced Security Features
  • Intelligent rate-limiting protection
  • Optimized access experience for mainland China
• ⚙️ Optimized System Configuration
  • DHCP service disabled to focus on DNS functionality
• 🔄 DDNS Support
• 🌉 Proxy Support
  • Download configuration files via proxy
  • DoH/DoT proxy support
• 🚦 DNS Split-Horizon Support
• 🚫 Anti-addiction App List Support

Managed Service Advantages

We provide a professional DNS hosting service with the following characteristics:

• 🏢 Deployed on Alibaba Cloud Hangzhou nodes
• 🌐 Comprehensive protocol support
  • IPv6 support, directly connected to mainstream IPv6 upstreams
  • DoT (DNS over TLS)
  • DoH (DNS over HTTPS)
  • HTTP/3 support, significantly reducing latency
• 📊 Powerful rule management
  • Support for importing third-party allow/deny lists
  • Capacity for 1 million rules
• 📝 Comprehensive logging and statistics
  • 72-hour query log retention
  • 24-hour detailed statistical analysis
• ⚖️ Load balancing
  • Multi-server distributed deployment
  • Intelligent load distribution
• 💰 Competitive pricing

Performance & Effectiveness Evaluation

Ad blocking at the DNS layer has unique advantages:

• 💪 Strengths

  • Zero additional power consumption
  • Coverage across all devices
  • Reduced device network wake-up frequency
  • Fewer invalid data loads

• ⚠️ Limitations

  • Lower blocking accuracy compared to browser extensions
  • Cannot achieve the filtering effect of MITM solutions

Especially suitable for mobile device usage scenarios, balancing privacy protection with battery life.

Full Support for HTTP/3 Protocol

NullPrivate has fully implemented support for the HTTP/3 protocol. All existing users will be automatically upgraded to enjoy the performance improvements brought by HTTP/3 without requiring any additional configuration.

Important Update Notes

• iOS Users: Can now directly use HTTP/3 via DoH protocol for lower network latency
• Android Users: Due to system limitations, DoT protocol is still used; support will be added after future Google updates
• Performance Improvement: Significantly faster initial response time compared to HTTP/2 with quicker connection establishment
• Smart Fallback: Automatically switches to HTTP/2 in network environments without HTTP/3 support to ensure service stability

In-depth Technical Analysis of HTTP/3

As the latest version of the HTTP protocol, HTTP/3 brings multiple revolutionary technical advantages based on Google’s QUIC transport protocol:

Core Features

1. QUIC Protocol over UDP

   • Significantly reduces connection establishment time
   • Improved multiplexing capabilities
   • Smarter packet loss handling mechanisms

2. Optimized Performance

   • Zero round-trip time (0-RTT)
   • Enhanced congestion control
   • Connection migration support

3. Enhanced Security

   • Integrated TLS 1.3
   • Encrypted handshake process
   • Reduced risk of man-in-the-middle attacks

Connection Establishment Comparison

Usage Recommendations

• Ensure your client supports HTTP/3 protocol
• Keep client software updated
• System will automatically downgrade to HTTP/2 in restricted network environments

Important Considerations

• Some regional networks may restrict UDP traffic, affecting HTTP/3 performance
• Performance may vary across different network environments
• System automatically selects optimal protocol based on network conditions

Reference Materials

• HTTP/3 Specification
• QUIC Protocol Deep Dive
• IETF HTTP/3 Standard

Introducing Custom Client Name Feature

Feature Overview

To enhance user experience, NullPrivate now supports custom client naming. This feature enables you to set unique identifiers for different devices, making device management more intuitive and convenient.

Configuration Guide

Configuration methods vary slightly depending on device type:

Android Devices

Simply add a custom prefix before the domain name using this format:

{device-name}.{original-domain}

Example: xiaomi-15pro.xxxxxxxx.nullprivate.com

iOS Devices

1. Navigate to the “Setup Guide” page
2. Enter your custom name in the “Client ID” field
3. Download and apply the new configuration profile

Browser Configuration (DoH)

Add custom identifiers after the original DoH address:

Original format:

https://xxxxxxxx.nullprivate.com/dns-query

New format:

https://xxxxxxxx.nullprivate.com/dns-query/{device-identifier}

Example: https://xxxxxxxx.nullprivate.com/dns-query/pc1-browser

Usage Recommendations

• Use meaningful identifiers like device model, location, or purpose
• Avoid special characters - use letters, numbers, and hyphens
• Maintain consistent naming conventions for easier management

Important Notes

• Custom names only affect display and won’t impact service performance
• Configuration must be reapplied after name changes take effect
• We recommend saving device configuration details for future reference

The Necessity of Ad Blocking: Safeguarding Attention and Privacy in the Digital Age

Deconstructing the Modern Advertising Ecosystem

The Advertiser Profit Model

The contemporary advertising system rests on a complex chain of interests:

• Advertisers connect marketers and users through media platforms
• Revenue comes from marketers’ placement fees, not from users
• The goal is to maximize “conversion rates”—turning ad viewers into paying customers

The Battle for Conversion

In this war for attention:

• Higher conversion rates translate into higher ad prices
• Ad-delivery efficiency directly affects revenue
• “Personalized targeting” has become the core strategy for boosting conversions

The Truth Behind Personalized Ads

The Depth of Data Collection

Modern ad systems harvest user information through multiple channels:

• Device identifiers and operating-system data
• Cross-platform behavioral tracking
• Social-relationship network analysis
• Consumer-habit profiling

The Trap of Precise Targeting

Seemingly convenient personalized feeds hide real risks:

• Exploiting cognitive biases to manufacture demand
• Amplifying latent user anxieties
• Creating false urgency

How Advertising Erodes Attention

The Cost of the Attention Economy

• Frequent interruptions undermine productivity
• Distorts decision-making ability
• Increases cognitive load
• Blurs the boundary of genuine needs

The Evolution of Ad Strategies

Modern advertising has moved beyond simple information delivery to:

• Forced memory implantation
• Emotional stimulation
• Anxiety marketing
• Social pressure

Strategies for Self-Protection

Core Protective Measures

1. Privacy First

   • Restrict app permissions
   • Control data sharing
   • Use privacy-protection tools

2. Attention Management

   • Set focused time blocks
   • Build information-filtering mechanisms
   • Cultivate the habit of actively seeking information

3. Consumption Decision Control

   • Establish a needs-assessment system
   • Delay purchase decisions
   • Maintain rational judgment

Technical Support: Cyber Savvy

In this data-driven era, maintaining “cyber savvy”—caution and wisdom in the digital realm—is vital. This includes:

• Managing digital footprints
• Protecting personal privacy
• Controlling information flow

Solutions

“NingPing” is a comprehensive protection suite that goes beyond ad blocking to help users:

• Safeguard personal privacy
• Optimize browsing experiences
• Reduce attention fragmentation
• Provide a controllable information environment

Let’s reclaim our digital lives—starting by rejecting intrusive ads.

Service Resource Optimization Strategy Guide

Background

As user numbers grow and feature demands increase, we have observed that certain high-resource-consumption configuration options can lead to service instability. To ensure service quality, we conducted an in-depth analysis and formulated a corresponding optimization plan.

Resource Optimization Strategy

1. Filter Update Mechanism Optimization

Current Situation

• Some users have configured hourly filter updates
• Each update requires a full download-parse-deduplication cycle
• International bandwidth limitations prolong update times
• Server resources remain under continuous high load

Optimization Plan

We have adjusted the minimum update interval to 72 hours for the following reasons:

• Most filter lists update on a 24–72 hour cycle
• Reduces ineffective resource consumption
• Ensures service stability
• Improves bandwidth utilization efficiency

Impact Assessment

• Positive impacts
  • More stable service response
  • More reasonable resource usage
  • Reduced system load
• Minimal impact
  • Rule updates still occur within a reasonable cycle
  • No effect on protection efficacy

2. Parallel Request Strategy

Current Situation

Most users currently have parallel requests enabled, but under the existing architecture the benefits are limited:

• Latency differences among Alibaba Cloud upstream services are typically within 5 ms
• May trigger Alibaba Cloud public service request-rate limits
• Adds unnecessary system overhead

Usage Recommendations

• We recommend using load-balancing mode
• Parallel requests are suitable for:
  • Scenarios with significant upstream latency differences (>200 ms)
  • Cases of unstable service quality
  • Cross-border access scenarios

Note: We have not yet observed any throttling issues caused by parallel requests, so this feature remains available for now.

3. Third-Party List Management

Security Considerations

To ensure system stability, we have temporarily disabled support for certain third-party lists:

• External list sizes are unpredictable
• May lead to resource overruns
• Service stability cannot be guaranteed

Future Plans

We are researching a safer third-party list management solution so that this feature can be re-enabled in the future.

Basic Memory Limit Adjustment

Some users’ environments restart frequently; checking the logs shows the exit reason is memory usage hitting the 300 MB limit, causing a forced shutdown.

We are now raising the per-container limit to 500 MB to alleviate the restart issue.

If your environment experiences login or restart problems, please don’t hesitate to contact us at any time—solving customer issues is our responsibility.

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.

Always Here to Support You

Quick Start Guide

To help you get up and running with our service as smoothly as possible, we’ve prepared a detailed User Guide.

Thoughtful Support Service

Personalized Guidance

We understand that new users may face challenges when first getting started. Therefore, we:

• Continuously refine the structure of our product documentation
• Provide clear configuration guides
• Have prepared an extensive FAQ

Timely Response

While we employ a registration-free system to protect user privacy, that does not compromise the support we provide. You can reach us through the following channels:

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.

How to Set Up a Dedicated Link

Some paid AdGuard Home services provide a dedicated link but do not allow users to access the admin panel; the provider manages the rules on their behalf.

This indicates that they do not offer a private admin backend; the service is simply delivered through a domain-based reverse proxy, keeping costs relatively low.

You need to rent a server to run AdGuard Home and configure an Nginx reverse proxy to achieve this functionality.

Taking the service link 5r69hxdx9onl70hp.example.com as an example, the key Nginx configuration is as follows:

http {
  server {
    listen 1080;
    server_name 5r69hxdx9onl70hp.example.com;
    location / {
      proxy_pass http://worker.example.com:5002;
      proxy_set_header Host $http_host;
    }
  }
  server {
    listen 1443 ssl;
    server_name 5r69hxdx9onl70hp.example.com;
    ssl_certificate /app/data/certs/5r69hxdx9onl70hp/fullchain.pem;
    ssl_certificate_key /app/data/certs/5r69hxdx9onl70hp/privkey.pem;
    location / {
      proxy_pass https://worker.example.com:5003;
      proxy_set_header Host $http_host;
    }
  }
}
stream {
  ssl_protocols TLSv1.2 TLSv1.3 SSLv3;
  map $ssl_preread_server_name $targetBackend {
    5r69hxdx9onl70hp.example.com worker.internal.com:5004;
  }
  server {
    listen 1853;
    proxy_pass $targetBackend;
    ssl_preread on;
  }
}

For each paying user you only need to add one similar Nginx block and point the domain’s DNS to the server. When the number of users grows and load on a single application instance becomes high, you can proxy to different back ends.

Such services cannot achieve true personalization; users must be able to enter the admin panel to truly control their own browsing data. This is the advantage of our private service—each user truly has an exclusive instance and can use all NullPrivate features.

All-new Upgrade – Enhanced Ad-blocking Rules

Rule Update Notes

To meet users’ demand for more robust ad blocking, we’ve completely overhauled our filtering rule strategy. The new version significantly improves ad-filtering effectiveness while keeping false-positives low. This update stems from user feedback; on the premise of ensuring normal website access, we have added more precise interception rules.

Rule List Overview

We have compiled the following professional rule lists; you can choose the ones that fit your needs:

Basic Protection Rules

Content Filtering Rules

Usage Recommendations

1. Step-by-Step Adoption

   • Start with the basic protection rules
   • Gradually add other rules as required
   • Review and update lists periodically

2. Performance Optimization

   • Avoid enabling too many rules at once
   • Prioritize the rules most relevant to your needs
   • Clean up unused rules on a regular basis

3. Troubleshooting

   • Record and report false-positives promptly
   • Temporarily disable a specific rule for testing
   • Utilize custom whitelists when necessary

Notes

• Certain rules may affect normal access to some sites
• We recommend checking for rule updates regularly
• If frequent false-positives occur, please contact us immediately

For users who need more flexible control, we offer a Pro service that supports fully custom rule configuration. Should you have any questions, feel free to reach out.

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.

Trial Service Details

As a provider focused on delivering custom ad-filtering rules, we understand the considerations users have when choosing a service. Although our operating costs are high, we remain committed to giving users maximum customization flexibility.

To let you fully appreciate the value of our service, we’ve launched an exceptional trial plan. This version includes all premium features and is identical to the paid service, allowing you to experience the unique advantages of customized filtering with zero risk.

Trial notes:

• The discounted price is available only for first-time use
• Renewals require selecting a paid service plan
• Thanks to our account-free design, the trial can be purchased repeatedly
• Each new purchase creates a completely fresh service instance
• Renewals preserve all existing configurations of the original instance

We look forward to your experiencing this premium service. If you encounter any issues during use, our support team is ready to provide professional assistance at any time.

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.