twoone-3/AdGuardHomeForRoot for Android DNS Filtering
A module to easily execute AdGuardHome on Android
At a glance
- What is it?
- AdGuardHome for Root runs AdGuardHome as a local DNS service on rooted Android devices through Magisk, KernelSU, or APatch. It fits users who want DNS filtering without a VPN, although password, compatibility, and recovery details require attention.
- Who is it for?
- Adopt this module if you already operate a rooted Android device and want AdGuardHome available as a local DNS service without Android's VPN interface. Do not adopt it if you need a non-root installation or a README-documented rollback procedure.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 7 days ago.
- What is it written in?
- Mainly Shell, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
AdGuardHomeForRoot solves local Android DNS filtering
twoone-3/AdGuardHomeForRoot packages AdGuardHome for use as a local DNS service on Android devices managed through Magisk, KernelSU, or APatch. The README identifies local filtering of advertisements, malware, and trackers as its purpose. Its natural audience is an Android user who has accepted root management and wants DNS control outside the usual VPN-based ad-blocking model.
The project addresses a specific deployment problem. AdGuardHome itself operates as a server, but turning that server into an integrated part of Android's DNS path requires installation, startup, forwarding, and configuration decisions. This repository provides a root-module wrapper for that work. It can also serve as a separately configured AdGuardHome installation, so it is not limited to a one-click blocking configuration.
That distinction matters for adoption. A user without root cannot use the installation path described by the README. Nor does the project present itself as an Android app from an application store. Its scope is rooted-device operation, where the user is already responsible for module state, root-manager compatibility, reboots, and recovery from a broken network configuration.
The README says the module is intended to coexist with proxy software such as NekoBox, FlClash, box for magisk, and akashaProxy. It does not publish a tested compatibility matrix or per-proxy setup instructions. The claim establishes an intended use case, not automatic interoperability with every network stack or release.
Local DNS forwarding feeds the AdGuardHome dashboard
The documented mechanism centers on an AdGuardHome process reachable through the Android device's loopback interface. The README lists an option to forward the device's own DNS requests to the local AdGuardHome server. In that mode, local requests enter AdGuardHome, pass through its filtering configuration, and use configured upstream DNS servers.
An administrator reaches the local dashboard through the address documented in the README. The dashboard provides query statistics, upstream DNS server selection, and custom-rule controls. This makes the web interface part of normal configuration rather than merely an installation status page.
The README identifies AWAvenue Ads Rule as the project's filtering rule source. It describes that source as lightweight, energy-saving, and less likely to produce false blocking. Those are the project's descriptions, not benchmark results. The repository page credits the TG-Twilight rule project separately, which is useful for distinguishing the Android module from the external rule collection it uses.
The documentation does not explain when the module retrieves rule updates, whether rule updates survive module replacement, or how DNS queries behave during service failure. It also does not document DHCP integration, split-DNS behavior, IPv6 handling, per-application exceptions, or upstream failure policy. Those details should remain separate from the confirmed architecture: a local server, optional local DNS forwarding, and a loopback management dashboard.
Installing the module on a rooted Android device
The first step is to open the repository's latest release page and download the published module. The README does not provide a shell command, package name, or command-line installer for this stage, so there is no verified CLI procedure to reproduce here.
Next, open Android's network settings and confirm that Private DNS is disabled. The README gives this navigation path:
1. Android Settings 2. Network & Internet 3. Advanced 4. Private DNS
The labels may vary between Android versions, but the important documented condition is explicit: Private DNS must be off. Leaving Android's private DNS configuration enabled may prevent requests from following the local forwarding path described by the project.
After downloading the module, open the supported root manager, install the module, and reboot the device. The README names Magisk, KernelSU, and APatch as installation environments. It gives no separate command for these steps because the operation belongs in the root manager interface.
After reboot, look for the module-running success notification. If it appears, open the local AdGuardHome dashboard at the documented loopback address. The initial credentials are listed as `root/root`. Once the dashboard responds, review the upstream DNS servers, inspect the custom-rule settings, and decide whether local DNS forwarding should remain enabled.
For advanced behavior and troubleshooting, the README directs users to `docs/index.md`. The short README does not document removal, rollback, backups, log inspection, or recovery after a failed startup.
Root modules, proxy tools, and DNS conflicts
The root requirement is both the project's defining advantage and its main adoption constraint. Magisk, KernelSU, and APatch provide the privileged environment needed to install the module and integrate the server into Android's network behavior. A device without any of these environments has no installation route documented by this project.
Proxy coexistence deserves more care than the README provides. NekoBox, FlClash, box for magisk, and akashaProxy are named as tools with which the module can work. However, DNS ownership can vary between Android, DHCP-provided settings, proxy applications, VPN services, and AdGuardHome. If two components each attempt to define the resolver path, the resulting behavior may not match the user's expectation.
The documented instruction to disable Private DNS addresses only one Android setting. It does not resolve conflicts involving every proxy client or third-party VPN. Users who already rely on a proxy application's built-in DNS control should review the active resolver path before enabling local forwarding.
The module also does not document behavior for Android work-profile restrictions, captive portals, enterprise DNS, mobile networks, or networks that supply DNS through DHCP. Its repository layout and README identify an Android root module, but they do not provide a device or network compatibility list. Adoption therefore depends on testing the specific configuration rather than treating general Android support as a blanket guarantee.
Dashboard credentials, rule coverage, and recovery gaps
The dashboard's documented `root/root` login is the first security detail an installer should notice. The README does not say whether the credentials rotate after first login, whether access is restricted to loopback throughout the service lifecycle, or whether an upgrade preserves them. Changing the default password through AdGuardHome would move it away from a publicly documented credential, although the README itself does not prescribe that step.
Rule quality is another dependency. AWAvenue Ads Rule supplies the module's stated advertisement filtering, but AdGuardHome also supports upstream servers and custom rules. Coverage and blocking behavior can therefore change with the selected list, custom entries, upstream resolver, and version of the installed service. The README does not promise complete blocking, and its reference to fewer false positives is not accompanied by comparative data.
Recovery is the most consequential documentation gap. The installation tutorial ends after opening the dashboard and points to `docs/index.md` for advanced information. It does not say how to uninstall the module, restore Android's previous DNS provider, disable forwarding from a shell, inspect service logs, or recover if AdGuardHome prevents expected network access. A user should identify the available recovery path through the project's documentation and root manager before installation.
The README does not identify the bundled AdGuardHome version either. That omission makes it harder to assess whether an Android system update or module update will retain settings, restart behavior, or compatibility.
Maintenance, upgrades, and the MIT license
The repository is not archived. Its last push was on 2026-10-16, and the listed releases include 20260825, 20260728, and 20260710. Those dates indicate recent project activity, but they do not prove compatibility with a particular Android device or root-manager version.
Upgrade cost cannot be quantified from the README. The repository includes `src/`, `version.json`, and `pack.ps1`, which identify a Shell-based module with separate packaging material. The README does not document whether AdGuardHome settings are preserved across releases, whether users must migrate configuration, or whether module upgrades replace a locally modified setup. It also does not state how external rule updates are installed.
The project declares the MIT license. That information tells readers which license applies to the repository, but this review does not interpret legal obligations or provide legal advice. Users still need to review the repository's `LICENSE` file for the exact terms, including notices associated with bundled or external software.
The main operational expense is likely configuration and recovery work rather than a documented fee. Root installation, rebooting, changing a default password, reviewing upstream DNS behavior, and validating proxy coexistence all require attention after an upgrade. The release history suggests continued packaging work, while the README leaves device-specific upgrade behavior undocumented.
Why choose this instead of a VPN ad blocker
A VPN-based ad blocker and AdGuardHomeForRoot intercept different integration points. A VPN blocker uses Android's VPN interface to receive device traffic. AdGuardHomeForRoot instead packages a DNS server into a root module and offers optional forwarding of the device's DNS requests to that local server. DNS filtering focuses on name resolution; it does not automatically become a full VPN traffic filter.
This difference can reduce reliance on the VPN interface, which the README describes as avoiding VPN complexity and performance loss. It also introduces root modules and service integration as dependencies. The trade-off is therefore not simply "better" or "worse." The first model fits users who already depend on VPN filtering, while this module fits rooted users who specifically want a local AdGuardHome service.
The repository also differs from deploying the upstream AdGuardHome project by itself. This project supplies the Android module package, installation instructions for supported root managers, optional local forwarding, and documented coexistence goals for selected proxy tools. It does not present a general server deployment guide for external clients.
Its missing remote-access, multi-client, backup, and recovery documentation makes it narrower than an organization-level DNS platform. For a single rooted Android device operated by someone who understands module and DNS management, that narrower scope can be appropriate. For a non-root phone or a formal service deployment, the documented architecture is the wrong fit.
Editorial conclusion
Adopt this module if you already operate a rooted Android device and want AdGuardHome available as a local DNS service without Android's VPN interface. Do not adopt it if you need a non-root installation or a README-documented rollback procedure. Verify first that Private DNS is disabled, review the default `root/root` dashboard credentials, and confirm that your network, proxy software, and recovery plan work with local DNS forwarding. The first concrete judgement is simple: the project is best treated as a rooted-device module, not as a generally supported Android DNS appliance.
Frequently asked questions
How do I install AdGuardHomeForRoot on Android?
Download a module from the repository's latest release page, disable Private DNS in Android settings, install it through Magisk, KernelSU, or APatch, and reboot. The README expects a module-running notification after reboot.
Where is the AdGuardHomeForRoot dashboard and what are the default credentials?
The documented dashboard address is `http://127.0.0.1:3000`. The README lists the initial credentials as `root/root` and says the interface supports statistics, upstream DNS settings, and custom rules.
Does AdGuardHomeForRoot require root access?
Yes. It is packaged as an Android module for Magisk, KernelSU, and APatch. The README does not describe an installation path for an ordinary device without root.
Can AdGuardHomeForRoot work with proxy applications?
The README says it is designed to coexist with NekoBox, FlClash, box for magisk, and akashaProxy. It does not provide a compatibility matrix or detailed settings for individual proxy tools.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/twoone-3-adguardhomeforroot)Was this useful?