Which websites are blocked on my Wi-Fi?
Router filters, Pi-hole, parental controls, school and work networks: what you can and can't see. Safe nslookup, dig and curl checks explained.
"Which websites are blocked on my Wi-Fi?" is really two different questions. If you own the network, you can open the filter and read it. If you only use the network (a school, an office, a hotel), you cannot see the list, but you can test the sites you care about and learn how each one is treated. This guide covers both, with safe, generic commands.
Who can block, and what each one can see
| Layer | How it blocks | Can you see its list? |
|---|---|---|
| Router with parental controls | Category or domain lists, often by DNS | Yes, if you own the router (admin page) |
| DNS filter (Pi-hole, AdGuard Home, a "family" DNS) | Returns no answer or a fake one for listed domains | Yes, if you run it. A hosted filter shows rules in its dashboard |
| School or office network | Firewall, web proxy or DNS policy | Usually no. Ask the network administrator |
| ISP | DNS, SNI/DPI or IP blocking, often by legal order | No. There is no public per-customer list |
| Your own device | Content blockers, Private DNS, a VPN or proxy app | Yes, in your device settings |
Two points worth knowing. First, a network operator normally sees the domain names you connect to (DNS queries and the SNI field), but not the page contents of HTTPS sites. Second, a filter that returns a block page is a courtesy. Many filters just fail silently, which is why testing matters.
If you own the network
- Router admin page. Look for "parental controls", "access control", "website filter" or "DNS". Many routers also let you set a custom DNS server, which changes who filters.
- Pi-hole or AdGuard Home. Their query logs list every domain a device asked for and whether it was blocked. Searching the log for a domain answers the question for that domain.
- A hosted family DNS. If your router points to such a service, its dashboard or its documentation lists the categories it blocks.
Be fair to the people on your network: a filter that quietly blocks things surprises users, so tell them what it does.
If you only use the network: test sites yourself
The commands below are generic and safe. They only ask normal questions that any browser would ask. Replace example.com with the site you want to test. On Windows, nslookup and curl work in a terminal. On macOS and Linux, dig is usually available as well.
1. Ask your network's DNS
nslookup example.com
dig example.com +shortThis uses whichever resolver your connection gave you (often the router, which forwards to the ISP).
2. Ask a public resolver for the same name
nslookup example.com 1.1.1.1
dig @1.1.1.1 example.com +short
dig @9.9.9.9 example.com +shortThese ask Cloudflare and Quad9 directly. Some networks redirect all DNS to their own server, in which case both commands return the same answer. If so, use encrypted DNS (DoH or DoT) for a true comparison, because encrypted queries cannot be quietly redirected.
3. Test the connection
curl -I https://example.com
curl -I --connect-timeout 10 https://example.com
curl -I -v http://example.com-I asks only for headers, -v shows the connection steps, and --connect-timeout stops it waiting forever.
4. Separate DNS from the connection
Once you have a good address from the public resolver, ask curl to use it instead of your network's DNS:
curl -I --resolve example.com:443:203.0.113.10 https://example.comReplace 203.0.113.10 with the address you got from the public resolver. This keeps the correct site name but skips your network's DNS.
What each outcome means
| Result | Most likely meaning |
|---|---|
Network DNS fails or returns a different address, public resolver returns a working one, and curl works with --resolve | DNS blocking or a broken DNS server. Encrypted DNS should fix it |
| Both DNS answers agree, TCP connects, but HTTPS resets during the handshake | Name (SNI/DPI) filtering is likely |
| Both DNS answers agree, the connection times out every time | IP or firewall block, or the server is down |
| You get an HTTP page that says access is restricted | A visible block page, from a proxy or filter. The message often names who runs it |
| Everything works | Not blocked at this layer. Check the app or the site itself |
Different addresses are not proof of blocking by themselves, because large sites send different servers to different networks. Judge by whether the address actually serves the site.
Doing the same on a phone with GreenTunnel
A phone has no dig. GreenTunnel packages the same logic in two features:
- Inspect URL compares your ISP's DNS with encrypted DNS, tests a direct connection to the real IP, and tries HTTPS with and without bypass. It names the likely cause for one domain at a time. See Is a site blocked on your network?
- Requester lists which apps connected where and how each connection was handled: Bypass, Direct or Error. It will not tell you what the network blocks in general, but it shows which of the sites you actually use are failing. See Requester.
Together they answer the practical question: "For the sites I use, what does this Wi-Fi do, and does a local technique help?" They do not reveal the network's filter list, and nothing a visitor can run can do that. The checks run on your device and we do not collect the domains you test.
What you cannot find out
- The network's complete block list, unless you manage it.
- Who set up a rule and why.
- Whether a rule changes at certain times, such as school hours.
Next steps: How to check if a website is blocked on my Wi-Fi and How to unblock a website. GreenTunnel is free on Android and iPhone, with optional Premium. More on the home page.
FAQ
Can I see a list of blocked sites on public Wi-Fi?
No. Operators do not publish them and the Wi-Fi does not expose them to guests. You can only test sites one at a time.
Does a Pi-hole block the same way as an ISP?
Both usually work at the DNS layer, answering with nothing or a fake address. A Pi-hole is under your control and logs what it blocks. An ISP may add SNI or IP blocking, which DNS tools cannot see.
Is running nslookup or dig on a network I do not own allowed?
These commands send the same ordinary DNS and HTTPS requests your browser sends. Still, respect the network's acceptable-use policy and do not run scanning or flooding tools.
Why do I get the same DNS answer from 1.1.1.1 as from my router?
Some networks transparently redirect plain DNS to their own resolver, so your query to 1.1.1.1 never reaches it. Encrypted DNS avoids that.
Sources
- IETF, RFC 8484: DNS Queries over HTTPS.
- IETF, RFC 8446: TLS 1.3 (the server_name extension that exposes the site name).
- Pi-hole, documentation (query log).
- curl, command-line manual (
-I,--resolve,--connect-timeout).
