Site Not Loading on Jio or Airtel but Works Elsewhere? Why, and How to Fix It

Why would a site work on one ISP and not another?

Between a visitor and your server sits their internet service provider: its DNS resolvers, its routers, its links to other networks and any filtering it applies. Each Indian ISP runs this differently. When a site fails on one network only, the cause is almost always in that path, not on your server, which is answering everyone else normally.

There are six common causes. They produce different symptoms, so the first job is to work out which one you are looking at.

• ISP DNS resolversMost phones and home routers use the ISP's own DNS resolvers by default. If those resolvers return a wrong, stale, empty or redirected answer for your domain, the site fails on that ISP only. This includes resolvers that have not picked up a DNS change yet, resolvers that fail DNSSEC validation for your zone, and resolvers that answer a blocked domain with the address of a block page (a DNS sinkhole).
• Blocks by government or court orderIndian ISPs are required to block access to specific domains, URLs or IP addresses when directed by the government or by a court. Each ISP implements orders with its own methods and timing, so a block can appear on one network before another. Sites on shared platforms can be caught when an order names the shared domain or IP address rather than one customer.
• IPv6 path problemsSome Indian networks, mobile networks in particular, hand most devices an IPv6 address, and devices prefer IPv6 when a site publishes an AAAA record. If your IPv6 address, firewall or load balancer is misconfigured, visitors on those networks fail or wait for a slow fallback, while IPv4-only networks work fine.
• CDN and peering routesTraffic from each ISP reaches your server or CDN over that ISP's own links. A congested interconnect, a broken route, or a CDN mapping that sends one ISP's users to a distant or unhealthy edge can make a site slow or unreachable on one network only, often for hours, then fix itself.
• TLS and SNI interferenceDuring the TLS handshake the browser normally sends the site's name unencrypted in the Server Name Indication (SNI) field, unless Encrypted Client Hello is in use. Network filters can read it and reset or drop the connection. The symptom is a connection reset or timeout on HTTPS while DNS resolves correctly.
• Carrier-grade NATMobile carriers put many subscribers behind a small pool of shared public IPv4 addresses. If your firewall, WAF or rate limiter blocks or challenges one of those addresses because of someone else's traffic, many unrelated users on that carrier are blocked too.

Reading the symptoms

What the user sees narrows the cause down quickly.

• A page saying the site has been blocked, or a notice referring to an order or a department: a block, delivered by DNS or by an HTTP page.
• "Server not found" or DNS_PROBE errors: a DNS problem, either the ISP resolver or your own records.
• Connection reset (ERR_CONNECTION_RESET) on HTTPS, with DNS resolving correctly: TLS or SNI-based filtering, or a middlebox dropping the connection.
• Slow loading or timeouts that come and go: routing, peering or CDN edge problems, or an IPv6 path that fails before falling back to IPv4.
• An "Access denied", CAPTCHA or 403 page from your own CDN or WAF: your security rules blocking shared carrier IP addresses.
• Certificate warnings that only appear on one network: something on the path is intercepting HTTPS, or the visitor is being sent to a block page served on your hostname.

What a user can try

If you are a visitor, these steps tell you whether the problem is your network, and often get you in.

• Switch networksTry mobile data instead of Wi-Fi, or the other way round, or a different ISP. If the site works on one and not the other, the problem is in the network, not your device.
• Change DNSOn Android, set Private DNS to a public resolver such as dns.google or one.one.one.one. On a computer or router, set DNS to a public resolver like 8.8.8.8 or 1.1.1.1. If the site then loads, your ISP's resolver was the problem. This does not get around blocks applied by IP address or TLS filtering.
• Clear the DNS cacheRestart the browser and device, or on Windows run ipconfig /flushdns, so a stale answer is not reused.
• Try with IPv6 offIf your router or phone lets you, turn IPv6 off for a test. If the site starts working, the site owner has an IPv6 problem to fix.
• Report it to the siteTell the owner which ISP, which city, whether it is mobile or broadband, and the exact error. That information is what they need to diagnose it.

How site owners can diagnose it

As the owner you need evidence from the failing network, not from your laptop on office Wi-Fi. Ask an affected user, a colleague on that ISP, or a probe on that network to run these tests.

1. Compare DNS answers

Run nslookup yourdomain.com with the default resolver, then nslookup yourdomain.com 8.8.8.8 and nslookup yourdomain.com 1.1.1.1 (or dig yourdomain.com @8.8.8.8 on macOS and Linux). If the ISP resolver returns an address that is not yours, or no answer while public resolvers return the right one, the problem is DNS: a stale record, a DNSSEC failure, or a DNS-level block. The free DNS checker compares answers from several public resolvers, which shows whether your own records are consistent.

2. Bypass DNS with curl --resolve

curl -v --resolve yourdomain.com:443:203.0.113.10 https://yourdomain.com/ forces curl to connect to your real IP address (replace the example address) while still sending the right hostname in SNI and the Host header. If this works on the failing network, DNS is the cause. If it still fails, the block or failure is on the path or at the TLS layer. Watch where curl -v stops: during connect points at routing or IP blocking, a reset right after the Client Hello points at SNI filtering, and an HTML page you did not write points at an HTTP block page.

3. Test IPv4 and IPv6 separately

curl -4 -v https://yourdomain.com/ and curl -6 -v https://yourdomain.com/ test each protocol on its own. If IPv6 fails and IPv4 works, check that your AAAA record points at the right address, that the server or load balancer listens on IPv6, and that your firewall and security groups allow IPv6 traffic. If you cannot fix IPv6 quickly, removing the AAAA record makes clients use IPv4 while you do.

4. Trace the route

traceroute yourdomain.com (tracert on Windows), or better mtr, which repeats the trace and shows loss at each hop, shows where packets stop. Loss that starts inside the ISP's network and continues to the end points at the ISP or its interconnect; loss only at one middle hop that recovers later is usually a router de-prioritising trace packets and can be ignored. Save the output: your CDN or ISP will ask for it.

5. Check your own security layer

Look at your CDN and WAF logs for blocked or challenged requests from the affected ISP's address ranges. Rate limits per IP address and bot scores are the usual culprits with carrier-grade NAT, because hundreds of real users can share one address.

How to fix it or escalate

• DNS problemsFix any inconsistent records, check DNSSEC is valid end to end, and wait out or lower TTLs after changes. If one ISP's resolver keeps returning a wrong answer for a correct zone, report it to the ISP with your nslookup output.
• IPv6 problemsFix the IPv6 listener, routing or firewall, or remove the AAAA record until you can. Test from an IPv6-only connection afterwards.
• Routing and CDN problemsOpen a ticket with your CDN or hosting provider, with traceroute or mtr output from the failing ISP, the time window and the affected city. CDNs can often change how they serve one network faster than the ISP can fix a route.
• Your own WAF or rate limitsRaise per-IP limits for shared carrier ranges, rate limit by session or account rather than IP where you can, and prefer challenges over hard blocks.
• Suspected blocksConfirm it from several networks first: a block page or a DNS sinkhole answer is the clearest evidence. Contact the ISP's customer support and, if that does not resolve it, its published grievance channel, asking what is being blocked and on what basis. If an order covers your site or a shared address you use, moving to a dedicated IP or your own domain may help in the short term; challenging the order itself is a legal matter, so take advice from a lawyer.

While you work on it, tell your users. A status page note such as "Some Jio users cannot reach the site; other networks are not affected" saves support tickets and tells affected users to try another network in the meantime.

Why normal uptime monitoring misses this

Most uptime monitors, including SutramX's own regions, check from data centres. Data-centre networks use their own resolvers and their own routes, so they do not see a block applied by an Indian consumer ISP, an ISP resolver returning a sinkhole address, or a problem with that ISP's routes. They keep reporting the site as up, correctly for their own network and incorrectly for your users.

Seeing what Jio or Airtel users see takes checks from inside those networks: from home broadband and mobile connections, not servers.

Last-mile checks from Indian ISPs in SutramX

SutramX last-mile checks look at your site from Jio, Airtel, Vi, BSNL and ACT networks. They run through Globalping, a third-party network of probes hosted on home and mobile connections, so results are "checked from Jio networks", not from SutramX servers inside Jio. SutramX also supports its own last-mile probes on home broadband and mobile connections. Only the hostname and path are sent to Globalping; request headers, query strings and credentials never are.

• On-demand on every planOn an HTTP, API or DNS monitor, click "Check from Indian ISPs now" on the Last-mile (Indian ISPs) card. Results arrive in about 30 seconds. On-demand checks are rate-limited.
• Five states per ISPReachable, Blocked (an ISP block page, HTTP 451 or a DNS sinkhole), Unreachable (for example a timeout or DNS failure), Partly reachable, or Inconclusive when too few probes answer.
• Scheduled checks and noticesScheduled checks every 10 minutes are on Growth and Pro. When your site fails on one or two ISPs for at least 5 minutes while every data-centre region still reaches it, SutramX sends a notice such as "Unreachable for Jio users", and another when it clears.
• During incidentsWhen an incident opens on a monitor that matters to Indian users, SutramX also runs an ISP check automatically, so the incident's "Why this alert" panel can show an Internet provider (last mile) finding.

Jio and Airtel FAQ

Why does a website open on Wi-Fi but not on Jio mobile data?

Your Wi-Fi and Jio mobile data use different DNS resolvers, routes and often different IP versions. The usual causes are the mobile network's DNS answer, a block applied on that network, a broken IPv6 setup on the site, or the site's firewall blocking shared mobile IP addresses.

Does changing DNS fix a site blocked on Jio or Airtel?

Only if the block or fault is in the ISP's DNS. Blocks applied to IP addresses, or by filtering the TLS server name, still apply with a public resolver. Changing DNS is mainly a diagnostic: if it helps, you know where the problem is.

How can I tell if my site is blocked in India?

Test from several Indian ISPs, not from a data centre. A block page, a DNS answer that points at a block page, or HTTP 451 is clear evidence; consistent timeouts or resets on one ISP while others work are a strong hint. SutramX's on-demand last-mile check runs this test from five ISPs at once.

Next steps

• Checks from Jio, Airtel, Vi, BSNL and ACT networks
• Last-mile ISP check setup
• Uptime monitoring for India
• DNS checker across public resolvers