# Domain search: partial matching returns 0 results for an FQDN that is blocked
**URL:** https://discourse.pi-hole.net/t/domain-search-partial-matching-returns-0-results-for-an-fqdn-that-is-blocked/87780
**Category:** Help
**Created:** [September 28, 2026, 1:02pm UTC](https://discourse.pi-hole.net/t/domain-search-partial-matching-returns-0-results-for-an-fqdn-that-is-blocked/87780 "2026-09-28T13:02:55Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@Christoph\_Fischer](https://discourse.pi-hole.net/u/Christoph_Fischer)
#### Post date: [September 28, 2026, 1:02pm UTC](https://discourse.pi-hole.net/t/domain-search-partial-matching-returns-0-results-for-an-fqdn-that-is-blocked/87780/1 "2026-09-28T13:02:55Z")
**Problem**
In _Tools → Search Adlists_ (Find Domains In Lists), searching for a fully qualified domain with "Use partial matching" enabled returns 0 results, even though the domain is blocked by a list entry such as `||example.com^`. Partial matching only checks whether the search text is _contained_ in a list entry. `www.example.com` is not contained in `||example.com^`, so nothing is found. With partial matching disabled, the same search correctly shows the blocking list.
Users can wrongly conclude that a domain is not blocked. Related threads show that this is a recurring point of confusion:
- "Query Lists" - No results found for blocked domain (Feb 2020)
- Blocked (gravity) but domain isn't on any list (Mar 2025)
- Domain blocked by gravity, but not in a list? (May 2025)
**Suggestion**
1. Clarify the checkbox help text, e.g.: _"Use partial matching: lists all entries that contain your search text. To check whether a specific domain is blocked, leave this off."_
2. On 0 results in partial mode, show a hint: _"No list entry contains this text. This does not mean the domain is allowed, because entries like `||example.com^` also cover subdomains. To check whether this domain is blocked, search again without partial matching."_ Ideally with a "Search exactly" button.
The CLI already prints a hint from exact search to partial search when nothing is found ("Try partial matching with \> pihole -q --partial …"). The reverse hint for the web UI is missing.
Verified on Core version is v6.4.3 (Latest: v6.4.3)
Web version is v6.6 (Latest: v6.6)
FTL version is v6.7 (Latest: v6.7.1)
**Reproduction** (Pi-hole Web, Tools → Search Adlists), searching for www.mietpreisexplosion-stoppen.ch:
With "Use partial matching" enabled:
```auto
Found 0 domains partially matching 'www.mietpreisexplosion-stoppen.ch'.
Found 0 lists partially matching 'www.mietpreisexplosion-stoppen.ch'.
Number of results per type:
- 0 exact domain matches
- 0 regex domain matches
- 0 allowlist (antigravity) matches
- 0 blocklist (gravity) matches
```
With "Use partial matching" disabled:
Found 0 domains exactly matching 'www.mietpreisexplosion-stoppen.ch'.
Found 1 list exactly matching 'www.mietpreisexplosion-stoppen.ch':
- [https://raw.githubusercontent.com/RPiList/specials/master/Blocklisten/pornblock3](https://raw.githubusercontent.com/RPiList/specials/master/Blocklisten/pornblock3)
block list
added: 2023-12-01 23:28:44
last modified: 2023-12-01 23:28:44
last updated: 2026-09-28 17:54:44 (1'125'000 domains)
enabled, used in 1 group
no comment
matching entries:
- ||mietpreisexplosion-stoppen.ch^
Number of results per type:
- 0 exact domain matches
- 0 regex domain matches
- 0 allowlist (antigravity) matches
- 1 blocklist (gravity) matches
---
### Author:  [@DanSchaper](https://discourse.pi-hole.net/u/DanSchaper)
#### Post date: [September 29, 2026, 4:32pm UTC](https://discourse.pi-hole.net/t/domain-search-partial-matching-returns-0-results-for-an-fqdn-that-is-blocked/87780/2 "2026-09-29T16:32:05Z")
@rdwebdesign Is this a web repo issue?
---
### Author:  [@rdwebdesign](https://discourse.pi-hole.net/u/rdwebdesign)
#### Post date: [September 29, 2026, 5:43pm UTC](https://discourse.pi-hole.net/t/domain-search-partial-matching-returns-0-results-for-an-fqdn-that-is-blocked/87780/3 "2026-09-29T17:43:54Z")
No. The search is processed by FTL and returned by the API. The web interface only shows what is returned.
As explained above, the issue is:
the search can't find a partial match to the `www.example.com` string in the database because this string is not there, only `example.com` is there (in `||example.com^`). Then the search returns zero matches, which is different than expected.
The suggested solution (to add additional message/hint to the partial search results) only requires changes on the web interface code, but it doesn't actually change how the partial search works.
* * *
I'm thinking if it's possible to change how FTL execute the partial match search to return the correct list, in cases like this.
---
### Author:  [@DL6ER](https://discourse.pi-hole.net/u/DL6ER)
#### Post date: [September 30, 2026, 4:24pm UTC](https://discourse.pi-hole.net/t/domain-search-partial-matching-returns-0-results-for-an-fqdn-that-is-blocked/87780/4 "2026-09-30T16:24:22Z")
Exact matching already works for ABP-domains. But I see that exact matching is expected to be a subset of partial matches (the larger set). Fix tracked here:
>
>
> \# What does this implement/fix?
>
> \`/api/search?partial=true\` only ran \`LIKE '%ter…m%'\` over the gravity tables, so searching \`www.example.com\` did not find an ABP-style \`||example.com^\` - the stored row does not spell out the subdomains it covers. Exact search already looked the generated ABP patterns up, which made partial the weaker mode.
>
> Partial searches now run the same \`gen\_abp\_patterns()\` lookups, skipping the pattern built from the full search term because the substring search already returned that row. Each extra lookup hits \`idx\_gravity\`.
>
> \## How to test the change during review
>
> With an adlist in ABP format - the test fixture \`test/gravity.db.sql\` carries \`||special.gravity.ftl^\`:
>
> \`\`\`
> curl -s "http://pi.hole/api/search/sub.special.gravity.ftl?partial=true&sid=..." | jq .search.gravity
> \`\`\`
>
> returns the \`||special.gravity.ftl^\` row; before this change the array was empty. Add \`&debug=true\` to see the generated patterns. Exact matching is unchanged.
>
> Three new pytest cases in \`test/api/test\_api.py::TestDomainSearch\` cover it: the subdomain hit in gravity, the same in antigravity, and a no-duplicates check for a term both paths can reach.
>
> \## Additional information
>
> \*\*Related issue or feature (if applicable):\*\* N/A
>
> \*\*Pull request in \[docs\](https://github.com/pi-hole/docs) with documentation (if applicable):\*\* N/A
>
> \---
> \*\*By submitting this pull request, I confirm the following:\*\*
>
> 1. I have read and understood the \[contributors guide\](https://docs.pi-hole.net/guides/github/contributing/), as well as this entire template. I understand which branch to base my commits and Pull Requests against.
> 2. I have commented my proposed changes within the code.
> 3. I am willing to help maintain this change if there are issues with it later.
> 4. It is compatible with the \[EUPL 1.2 license\](https://opensource.org/licenses/EUPL-1.2)
> 5. I have squashed any insignificant commits. (\[\`git rebase\`\](https://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html))
> 6. My change does not modify \`src/dnsmasq/\`. That tree is a verbatim copy of upstream dnsmasq and we do not carry anything in it that deviates from upstream. Fixes have to go through the \[\`dnsmasq-discuss\` mailing list\](https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss) first, we merge them once they are in dnsmasq master.
>
> \## Checklist:
>
> \- \[x\] The code change is tested and works locally.
> \- \[x\] I based my code and PRs against the repository's \`development\` branch.
> \- \[x\] I \[signed off\](https://docs.pi-hole.net/guides/github/how-to-signoff/) all commits. Pi-hole enforces the \[DCO\](https://docs.pi-hole.net/guides/github/dco/) for all contributions
> \- \[x\] I \[signed\](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits) all my commits. Pi-hole requires signatures to verify authorship
> \- \[x\] I have read the above and my PR is ready for review.
P.S.: The current behavior is _documented_, but I see that it may not be the _expected_ behavior, the API documentation (`search.yaml`) said:
> ABP matches are not returned when partial matching is requested
That line is replaced in the PR.