AdGuard Home shows only one blocking rule when multiple filters match the same domain

[Shakura404]

Prerequisites

• I have checked the Wiki and Discussions and found no answer

• I have searched other issues and found no duplicates

• I want to report a bug and not ask a question or ask for help

• I have set up AdGuard Home correctly and configured clients to use it. (Use the Discussions for help with installing and configuring clients.)

Platform (OS and CPU architecture)

Linux, ARM64

Installation

GitHub releases or script from README

Setup

On a router, DHCP is handled by the router

AdGuard Home version

v0.107.72

Action

1. Configure AdGuard Home with multiple blocklists enabled (e.g. OISD Blocklist Big and other lists that contain the same domain).
2. Query a domain that exists in multiple enabled blocklists.
3. Open the query log and inspect the “Response details” for the blocked request.

Expected result

When a domain is blocked, AdGuard Home should list all matching blocking rules and blocklists that caused the block, not just a single rule. This allows full visibility into why a request was blocked and makes troubleshooting and filter management easier, similar to how NextDNS displays multiple matching filters.

Actual result

When a domain is blocked, AdGuard Home only shows one blocking rule / blocklist in the “Response details”, even when the same domain is present in multiple enabled blocklists. Other matching filters are not shown, which makes it impossible to see the full set of rules that contributed to the block.

Additional information and/or screenshots

No response

[Dynamic5912]

Why use multiple lists blocking the same domains?

What exactly are you looking to achieve?

[Shakura404]

Using multiple blocklists is intentional and common in layered DNS filtering setups. Different lists serve different purposes (ads, tracking, telemetry, malware, phishing) and have different update cadences, sources, and trust models. Overlap is expected and desirable because it provides redundancy and coverage assurance when lists diverge or change over time.

I’m looking for full transparency and debuggability. When a domain is blocked, I want to see all blocklists and rules that matched, not just the first one evaluated. This helps with:

• Understanding why something is blocked
• Deciding which lists are redundant or can be removed
• Troubleshooting false positives
• Auditing filter effectiveness over time

NextDNS already exposes this information and it’s extremely useful for filter tuning. AdGuard Home already evaluates multiple rules internally. I’m only asking for visibility into that existing behavior.

[Dynamic5912]

You need to reevaluate your list selections.

Look at using "all in one" lists like Hagezi's and you'll have no overlaps, better blocking and less resources used with multiple lists.

[Shakura404]

I understand the suggestion, but list selection is not the issue being discussed here.

Overlapping entries are expected in many real-world setups, especially when combining lists with different scopes, sources, and trust models. Redundancy is often intentional and used for verification, auditing, and resilience against upstream changes.

The request is not about improving blocking efficiency or reducing resource usage.
It is about visibility and transparency: when AdGuard Home blocks a domain, all matching rules are already evaluated internally, but only one is shown to the user.

Exposing all matching rules would:

• Improve troubleshooting and false-positive analysis
• Help users rationalize or prune their lists based on actual overlap
• Bring AdGuard Home in line with tooling like NextDNS that already provides this insight
• Exposing all matching rules is also valuable for security researchers and advanced users who rely on full visibility for analysis, validation, and auditing of DNS-based blocking decisions, and it should be relatively straightforward to integrate since the evaluation already happens internally.

Users who prefer “all-in-one” lists are free to do so, but that shouldn’t preclude better introspection for those who don’t.

[Dynamic5912]

I believe AGH also filters out duplicate domains from lists. I may be wrong there.

But what you're asking for is down to your list housekeeping still.

There is absolutely no need to use lists that have duplicate or overlapping domains. It's just overkill.

[Shakura404]

Regardless of list hygiene, AdGuard Home already evaluates multiple rules internally. The request is simply to expose that information to the user. Visibility into system behavior is a legitimate requirement, especially for debugging, auditing, and security research.

Whether someone chooses one list or many is a user preference. Tooling should not assume a single “correct” usage pattern or hide relevant information based on that assumption.

[tjharman]

Why would a filter process a request and block it, but then waste time going down the chain to see if any other lists also block it? I would expect it makes a block decision and then in the name of saving CPU, stops processing any further.
I expect implementing what you're after would result in a performance hit.

[Shakura404]

AdGuard Home already processes and evaluates multiple rules internally. This is evident from the UI itself, which explicitly labels the field as “Rule(s)” (plural), not “Rule”. My screenshot shows this clearly. The evaluation already happens. The UI simply exposes only one matching rule.

The request is not to change the blocking logic or force additional processing, but to surface metadata that already exists. Any performance impact would be negligible compared to DNS resolution, logging, and UI rendering already being done.

This is a visibility / UX concern, not a filtering efficiency concern.

[Dynamic5912]

How do you know it happens, based on what could purely be a typo?

[Shakura404]

At this point, I think it’s best to leave the assessment and prioritization of this request to the maintainers.

What is important or useful varies between users and use cases, and the purpose of this issue is to request improved visibility, not to debate individual configuration preferences or speculate about implementation details.

Thanks for the input.