Use this page after every setup change
A block is not finished when one test site fails to load. It is finished when the common bypass paths fail from the device, account, browser, and network you actually use.
- Write down what you expect to be blocked: adult sites, specific sites, apps, browsers, VPNs, social platforms, stores, or all browsing except an allowlist.
- Use a harmless test target: a domain you already put in your blocklist, the filtering provider's own test page, or a neutral site category checker. Do not search for explicit content to test.
- Test from the daily account, not the administrator, parent, owner, or trusted-person account.
- Test Wi-Fi and mobile data separately. A router rule does not protect cellular data.
- Fix one failed test at a time, then rerun this checklist.
Fast scorecard
Use this table before you call the setup done.
| Area | Pass means | If it fails |
|---|---|---|
| Browsers | Blocked content fails in every installed browser and in private/incognito windows. | Remove extra browsers, block installs, add browser policy, or move to allowlist mode. |
| Apps | You cannot install a new browser, VPN, proxy, Tor app, alternate app store, or remote desktop app. | Tighten App Store, Google Play, Microsoft Store, package manager, or admin-password controls. |
| DNS | The device uses the intended filtering resolver and cannot casually switch to another one. | Use standard-user accounts, Private DNS/profile controls, router DNS enforcement, and DoH/DoT policy. |
| Network | The same rule works on Wi-Fi, Ethernet, guest Wi-Fi, and mobile data where applicable. | Add mobile-device controls, turn off guest networks, or configure router rules per network/VLAN. |
| Accounts | The daily user cannot change parent settings, Screen Time, Family Link, Family Safety, or admin settings. | Move passcodes, parent accounts, admin passwords, and recovery paths to a trusted person. |
| Reset paths | You cannot factory reset, recover, powerwash, or re-admin the device and immediately regain control. | Use the recovery audit and trusted-person handoff. Device-level filters alone are not enough. |
1. Browser test
Many setups only filter one browser. Test every place a webpage can open.
Browsers to test
- Safari, Chrome, Edge, Firefox, Brave, Arc, Opera, Vivaldi, DuckDuckGo Browser, Samsung Internet, and any portable browser.
- Private, incognito, guest, temporary, or container windows.
- Separate browser profiles and signed-out states.
- In-app browsers inside Reddit, Discord, X, Instagram, Telegram, Slack, email clients, and messaging apps.
What to try
- Open your harmless test domain in each browser.
- Open it again in private/incognito mode.
- Open a link to it from a messaging or social app.
- Try a different browser profile.
- Confirm the browser cannot turn on Secure DNS, DoH, a proxy extension, or a VPN extension.
If only one browser is filtered, that browser should be the only browser available to the daily account, or the filtering should move down to DNS/router/account policy.
2. App install test
A blocker fails quickly if you can install a new browser, VPN, proxy, or alternate app store.
- From the daily account, try installing a common browser you do not currently use.
- Try installing a VPN app, proxy app, Tor browser, remote desktop app, and alternate app store.
- Try installing a browser extension that can proxy, translate, archive, mirror, or unblock websites.
- Try deleting the blocker, DNS profile, accountability app, or managed browser.
- Confirm each attempt requires the trusted person, parent account, admin account, or store approval.
Do not install risky software just to test. Stop at the approval prompt. The point is to confirm that installation is blocked or requires another person.
Technical-user bypasses to test
Run this section if you know your way around browsers, package managers, remote access, virtual machines, or developer tools.
- Portable browsers that run from Downloads, USB drives, cloud drives, or user-writable folders.
- Remote desktop tools such as Chrome Remote Desktop, AnyDesk, TeamViewer, VNC, RDP, SSH, cloud workstations, cloud IDEs, or unmanaged virtual desktops.
- Package managers and developer tools: winget, Chocolatey, Homebrew, MacPorts, Flatpak, Snap, AppImage, WSL, Docker, virtual machines, and Linux containers.
- Browser extension stores, userscripts, translation or proxy extensions, archive mirrors, cached pages, and web-based proxy tools.
- Generative AI, chat, image, or roleplay tools if those are a content bypass for the user.
- Old phones, tablets, spare laptops, smart TVs, game consoles, and shared devices that still have unfiltered browsers or apps.
The right fix is usually not another blocklist entry. The right fix is removing admin rights, blocking unapproved installs, and moving recovery to the trusted person.
3. DNS and encrypted-DNS test
DNS filtering fails when the device, browser, or app can choose a different resolver.
Basic checks
- Check the DNS servers shown in network settings.
- Check the browser's Secure DNS / DNS-over-HTTPS setting.
- On Android, check Settings -> Network & internet -> Private DNS.
- On iPhone/iPad, check Settings -> General -> VPN & Device Management for DNS or VPN profiles.
- On routers, check both IPv4 DNS and IPv6 DNS.
Technical checks
# macOS: show DNS configuration
scutil --dns | grep nameserver
networksetup -getdnsservers Wi-Fi
# Windows: show adapters and DNS
ipconfig /all
# Linux: show systemd-resolved state
resolvectl status
# Test whether direct external DNS still answers
nslookup example.com 1.1.1.1If
nslookup example.com 1.1.1.1 works from a home network where you intended to force filtered DNS, clients can probably bypass your DNS filter. Add router DNS interception or blocking for outbound TCP/UDP port 53, and consider blocking DoT on port 853.4. Network test
- Test on normal home Wi-Fi.
- Test on guest Wi-Fi.
- Test on Ethernet if the device has it.
- Turn Wi-Fi off and test on mobile data.
- On Apple devices, test iCloud Private Relay / Limit IP Address Tracking on Wi-Fi and cellular.
- Test using a mobile hotspot from another phone if that is available to you.
- Test on a public Wi-Fi network only if you can do so safely and legally.
Router blocking is useful, but it only applies to traffic that uses that router. Phones, tablets, laptops, and hotspots need their own layers.
5. Account and recovery test
Do not test by actually resetting passwords. Test whether you still hold the reset path.
| Question | Pass | Fail |
|---|---|---|
| Can you change the Screen Time passcode? | No, the trusted person holds it and recovery. | You know the passcode or can recover it alone. |
| Can you sign into the Family Link parent account? | No, parent credentials and recovery are off-device. | The parent account password is saved, recoverable, or known. |
| Can you become administrator/root/owner? | No, admin credentials are held elsewhere. | You can approve prompts, use sudo, or create another admin. |
| Can you reset the router or DNS dashboard? | No, the login and recovery email are controlled by the trusted person. | You know the router password, ISP account, or DNS account recovery path. |
| Can you use saved passwords or backup codes? | No, they were removed, transferred, or sealed. | They are in your password manager, Notes, screenshots, email, or downloads. |
6. Reset and physical-access test
Ask these questions
- Can I factory reset the phone and set it up with my own account?
- Can I powerwash the Chromebook and become the owner?
- Can I reinstall Windows, macOS, or Linux and regain admin?
- Can I boot from external media?
- Can I reset the router with a physical button and set a new admin password?
- Can I retrieve a BitLocker, FileVault, Apple, Google, or Microsoft recovery key?
Hardening direction
- Move recovery keys and admin credentials to the trusted person.
- Use standard accounts for daily use.
- Use device management, supervision, or enterprise controls for serious lockout.
- Put the router in a less accessible location if physical reset is a real bypass.
- Do not rely on a device-level setting if a factory reset removes it.
When a test fails
- Name the bypass exactly: alternate browser, app install, DNS change, VPN, mobile data, admin access, recovery, or reset.
- Go to the matching page: Browser policy, Mobile data, Routers, Recovery audit, or Trusted person.
- Fix that one bypass.
- Run this page again.
More guides
Use these when you need a checklist, a specific bypass closed, or a clearer handoff plan.
Test your setup
Browser, DNS, mobile data, recovery, and reset-path tests.
Setup recipes
Direct paths for phones, laptops, technical users, and whole-home setups.
Recovery audit
Find passwords, backup codes, router logins, and reset paths.
Browser policy
Chrome, Edge, and Firefox policy examples.
Mobile data
Close cellular, Private DNS, VPN, and hotspot gaps.
Apps and platforms
Search, YouTube, social apps, app stores, TVs, and in-app browsers.
Router recipes
DNS enforcement, guest networks, IPv6, Pi-hole, and AdGuard Home.
Urge plan
What to do before trying to bypass.
Trusted handoff worksheet
Printable inventory for passcodes, recovery paths, and refusal rules.
Glossary
Plain-language definitions for DNS, DoH, VPNs, MDM, recovery keys, and more.