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. |
| Still switched on | The filter and the DNS setting are the ones you configured, and nothing has quietly reverted to automatic or been paused. | Check it weekly. If it changed and you do not remember doing it, treat that as the event, not as noise. |
| Undo paths | You cannot turn the protections off yourself: not the passcode, not the profile, not the sharing setting that lets another device do it for you. | Section 7 below. This is the test most setups quietly fail. |
| 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.
Test in-app browsers specifically, and test what the record shows
This is the test most setups skip, and it is the one that most often changes someone's plan. Tapping a link inside an app usually opens the page inside that app rather than in your browser, and whether that is filtered, and whether it is recorded, are two separate questions with two different answers.
- Pick three apps you actually use that show you links: a news or sports app, a social or forum app, and a messaging app.
- Send yourself a link to your harmless test domain and open it from inside each app rather than from the browser.
- Note whether the block appears. On iPhone the web restriction should apply inside these views; on Android, Chrome's blocklist is not applied inside System WebView, so expect apps like Instagram and Facebook to behave differently from ones that hand off to Chrome.
- Now check the record. Open your browser's history and look for those visits. Then check your DNS provider's log if you have one.
- Compare the two. The gap between them is the part of your activity that your accountability arrangement cannot see.
If the visits are filtered but absent from history, your block is working and your record is incomplete. Those need different fixes: allowlist mode for the block, and a record held outside the device for the visibility. Do not treat a clean history as evidence of a clean week until you have run this test and know what history actually captures.
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 and DoQ on port 853, TCP and UDP.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.
7. Can you undo it yourself?
Every test above asks whether content gets through. This one asks a different question, and it is the one most setups quietly fail: how long would it take you to switch all of this off? Run it a week after setup rather than on the same evening, because the honest answer changes once the novelty wears off.
Is the protection still actually on?
Start here, because things revert. A profile gets removed during a repair, an app update resets a toggle, a monthly quota runs out, or you changed something at midnight and do not remember.
- Check the filter setting itself is still what you chose, rather than back to unrestricted.
- On a phone, check the DNS setting still names your provider rather than Automatic. On a Mac, check the DNS servers in network settings are still the ones you intended, since an administrator can change them directly without touching the profile.
- Open your DNS provider's log and confirm it is still recording today. A log that stopped three weeks ago is not a record, and nobody gets an alert when it stops.
- If you pay for that service, check you have not exhausted a monthly allowance, because on some plans filtering and logging both stop when you do.
The undo paths worth checking by hand
- The passcode. On an Apple device, open the Screen Time passcode screen and tap Forgot Passcode?. If it offers to reset using an Apple Account whose password you know, you can undo everything in about a minute, no matter who typed the passcode. Fix it by having the trusted person set a new passcode and answer that recovery prompt with their own account.
- Administrator rights. On a Mac or PC, confirm your daily account is a standard account. If you can still authenticate an admin prompt, you can change DNS and remove profiles at will, and the rest of the setup is decoration.
If either of those worked, you do not yet have a setup, you have a preference. That is worth knowing plainly rather than discovering it during a bad week. Lock the DNS profile covers the fix for each platform.
Does the block reach inside other apps?
Worth doing once, because it is the gap that surprises people, and because a pass here tells you the filter is working below the browser rather than only inside it.
- Pick a harmless site you have blocked, or one simply not on your allowlist. Do not go looking for anything.
- Send yourself the link and open it from inside a news, forum or social app, so it opens in that app's own browser rather than yours.
- Repeat in a private or incognito window.
- Then look in your browser's history and see whether any of those visits appear.
If the pages were blocked but do not show up in history, that is the expected result on an iPhone and it is worth understanding: the block reaches those views, the record does not. That asymmetry is the whole argument for keeping a record somewhere off the device, which is what Accountability is about.
Put a reminder in your calendar to run this section monthly. Not the whole page, just this one. Setups do not usually fail dramatically; they fail by quietly reverting while everyone assumes they are still on.
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.