Guide · 5 min read

How to Test if Your Backend is Blocked by Indian ISPs

Your app stopped working for users in India and you are not sure why. Is it a Supabase outage? A bug in your code? Or an ISP-level DNS block? This guide walks you through a systematic process to diagnose whether Indian ISPs are blocking your backend, using nothing but a terminal and a browser.


Symptoms of an ISP block

Before running diagnostics, check whether you are seeing these telltale signs. If two or more of these match, an ISP block is the most likely cause.

ERR_CONNECTION_TIMED_OUT in the browser

API calls to *.supabase.co hang for 30+ seconds and then fail. The browser console shows a network error with no HTTP status code.

fetch() promises that never resolve

Your JavaScript fetch() calls to Supabase endpoints never return a response. They sit in a pending state until they time out.

Works on WiFi but not on mobile data (or vice versa)

Different ISPs have different blocking policies. Your app might work on Airtel broadband but fail on Jio mobile data, or the other way around.

Works with a VPN but not without

If turning on a VPN instantly fixes the problem, the issue is between your device and the destination - which points directly to an ISP-level block.

Works from non-Indian IPs but fails from India

Your teammates outside India can use the app just fine. Only users connecting from Indian IP addresses are affected.

Step 1: Quick DNS check

The fastest way to confirm a DNS block is to run a DNS lookup from your machine. If your ISP is poisoning DNS, the resolved IP address will be a sinkhole - not a real Supabase server.

What a blocked response looks like:

terminal
$ nslookup yourproject.supabase.co
Server: 198.18.0.1
Address: 198.18.0.1#53
Non-authoritative answer:
Name: yourproject.supabase.co
Address: 49.44.79.236 ← sinkhole IP (NOT Supabase)

What an unblocked response looks like:

terminal
$ nslookup yourproject.supabase.co
Server: 1.1.1.1
Address: 1.1.1.1#53
Non-authoritative answer:
Name: yourproject.supabase.co
Address: 13.228.225.19 ← real Supabase IP (AWS)

The sinkhole IP 49.44.79.236 belongs to Reliance Jio's network - it is not a Supabase server. Real Supabase IPs typically resolve to AWS addresses in ranges like 13.x.x.x or 54.x.x.x.

You can also use dig for a more detailed view:

terminal
# Using dig for more detail
dig yourproject.supabase.co +short
49.44.79.236 ← blocked (sinkhole)
# Compare with a public DNS resolver
dig @1.1.1.1 yourproject.supabase.co +short
13.228.225.19 ← real IP via Cloudflare DNS

Key indicator: If nslookup or dig returns an IP that does not belong to AWS or Supabase's infrastructure, your ISP is returning a poisoned DNS response. Common sinkhole IPs include 49.44.79.236 and similar addresses in the 49.x.x.x range on Jio networks.

Step 2: Test from multiple networks

ISP blocks are not uniform across India. One ISP may block a domain while another does not. Testing from multiple networks helps you understand the scope of the block and confirm it is ISP-specific rather than a global Supabase outage.

Use this simple curl command to test connectivity from each network:

terminal
# Test basic connectivity (should return JSON)
curl -s -o /dev/null -w "HTTP Status: %{{http_code}}\nTime: %{{time_total}}\n" \
https://yourproject.supabase.co/rest/v1/ \
-H "apikey: YOUR_ANON_KEY"
# If blocked, you will see:
curl: (28) Connection timed out after 30001 milliseconds
# If working, you will see:
HTTP Status: 200
Time: 0.342

Run this command on each network you have access to and record the results:

1

Jio mobile data (4G/5G)

Tether your phone or use a mobile hotspot. Jio is the most commonly reported blocked ISP.

2

Airtel broadband or mobile

Test from an Airtel connection to see if the block extends to India's second largest ISP.

3

VPN (non-Indian exit node)

Connect to a US or EU VPN server. If this works but direct connections do not, the block is confirmed.

Why blocks vary by ISP: Each Indian ISP implements government blocking orders independently. Jio might block a domain while BSNL does not. The blocking mechanism (DNS poisoning, DPI, or SNI filtering) can also differ, which is why testing from multiple networks is critical.

Step 3: Check with online tools

If you only have access to one network, online tools can test connectivity from servers around the world. This helps you determine whether the issue is India-specific or a global Supabase outage.

ping.pe

Enter yourproject.supabase.co and it pings from 30+ global locations. Look for failures specifically from Indian nodes (Mumbai, Chennai, Delhi).

check-host.net

Offers DNS, HTTP, TCP, and ping checks from servers worldwide. Run a DNS check to see which IPs are returned from Indian servers versus international ones.

Downdetector

Check if other Supabase users are reporting issues. A spike in reports from India with none from other countries is a strong signal of an ISP block.

Supabase Status

Visit status.supabase.com to check if there is a global outage. If Supabase reports all systems operational, the issue is on the network side.

The key pattern to look for: if international servers can reach yourproject.supabase.co successfully but Indian servers cannot, that is definitive evidence of an ISP-level block rather than a Supabase outage.

Step 4: Compare DNS resolvers

This test tells you what kind of blocking your ISP is using. Compare the DNS results from your ISP's default resolver against public DNS providers. The difference reveals whether the block is purely DNS-based or uses deeper inspection.

terminal
# 1. ISP's default DNS (likely blocked)
nslookup yourproject.supabase.co
Address: 49.44.79.236 ← sinkhole
# 2. Cloudflare DNS (1.1.1.1)
nslookup yourproject.supabase.co 1.1.1.1
Address: 13.228.225.19 ← real IP
# 3. Google DNS (8.8.8.8)
nslookup yourproject.supabase.co 8.8.8.8
Address: 13.228.225.19 ← real IP
# 4. Quad9 DNS (9.9.9.9)
nslookup yourproject.supabase.co 9.9.9.9
Address: 13.228.225.19 ← real IP

Now try to actually connect using the correct IP. This tells you if the ISP is doing more than DNS poisoning:

terminal
# Test if connection works after bypassing DNS
curl --resolve yourproject.supabase.co:443:13.228.225.19 \
https://yourproject.supabase.co/rest/v1/ \
-H "apikey: YOUR_ANON_KEY" \
-s -o /dev/null -w "HTTP: %{{http_code}}\n"

What the results mean

  • DNS returns sinkhole, but curl with --resolve works: Pure DNS block. Changing DNS on your machine may help for development, but your users are still affected.
  • DNS returns sinkhole, and curl with --resolve also fails: The ISP is using Deep Packet Inspection (DPI) or SNI filtering. They are inspecting the TLS handshake and blocking connections to *.supabase.co regardless of DNS. This is a more aggressive block.
  • Both scenarios require a reverse proxy: Whether the block is DNS-only or DPI-based, the fix is the same - route traffic through an unblocked domain using a Cloudflare Worker proxy.

Step 5: Verify with a browser script

You can run this quick diagnostic script directly in your browser's DevTools console. It tests connectivity to your Supabase project and reports the result in a way that is easy to share with your team or in a bug report.

browser console
async function testSupabaseAccess() {
const SUPABASE_URL =
'https://yourproject.supabase.co';
const ANON_KEY =
'your-anon-key';
console.log('Testing Supabase connectivity...');
const start = Date.now();
try {
const controller =
new AbortController();
const timeout =
setTimeout(() =>
controller.abort(), 10000);
const res = await fetch(
`${SUPABASE_URL}/rest/v1/`,
{
headers: {
'apikey': ANON_KEY,
'Authorization':
`Bearer ${ANON_KEY}`
},
signal: controller.signal
}
);
clearTimeout(timeout);
const ms = Date.now() - start;
console.log(
`PASS: ${res.status} in ${ms}ms`
);
} catch (err) {
const ms = Date.now() - start;
console.error(
`FAIL: ${err.message} after ${ms}ms`
);
console.error(
'Likely ISP block. Try VPN to confirm.'
);
}
}
testSupabaseAccess();

Open your browser's DevTools (press F12), go to the Console tab, paste this script, and replace the URL and key with your actual values. The output will tell you immediately whether the connection succeeds or fails and how long it took.

Interpreting the output: A response within 100-500ms with HTTP status 200 means the connection is working. If it times out after 10 seconds with an AbortError, the connection is being blocked. If you get a CORS error, the connection reached Supabase but the origin is not allowed - that is a different issue.

What to do if your backend IS blocked

If your tests confirm the block, do not panic. There are three paths forward depending on how much time and control you want:

1

Quick fix: Self-host a proxy

Self-hosted, under 60 seconds

Run one command to deploy a full-featured proxy on your own Cloudflare Workers account. Guided setup, auto-deploy.

npx create-jiobase
  • Full proxy: REST, Auth, Storage, Realtime (WebSocket), Edge Functions
  • CORS handling + service filtering included
  • Free on Cloudflare Workers free tier (100k requests/day)
Learn more
2

Managed fix: Use JioBase

Fully managed, under 60 seconds

Sign up, enter your Supabase URL, and get a proxy endpoint instantly. Includes WebSocket/Realtime support, analytics, rate limiting, and a dashboard. Change one URL in your code and you are done.

  • Full HTTP + WebSocket proxy
  • Dashboard with request analytics
  • Free tier: 50,000 requests/month
Start for free
3

Full tutorial: Build your own proxy

DIY, 30 minutes

Follow our step-by-step guide to build a Cloudflare Worker reverse proxy from scratch. Covers HTTP proxying, WebSocket support, CORS configuration, DNS setup, and deployment.

Read the full tutorial

Frequently Asked Questions

How do I know if it is an ISP block vs a Supabase outage?
Check status.supabase.com first. If Supabase reports all systems operational, it is not an outage. Then test from a VPN or ask someone outside India to try. If it works from non-Indian IPs but fails from Indian ones, it is an ISP block. You can also use ping.pe to test from global locations - if only Indian nodes fail, the ISP block is confirmed.
Does the block affect all Supabase projects or just mine?
The block targets the entire *.supabase.co domain, not individual projects. This means every Supabase project is affected, not just yours. You can verify this by running nslookup anyproject.supabase.co - all subdomains will resolve to the same sinkhole IP on affected ISPs.
Can I test the block from outside India?
Yes, but indirectly. Use online tools like check-host.net or ping.pe that have test servers in India. These tools will run DNS lookups and ping tests from Indian servers on your behalf. If those Indian nodes return sinkhole IPs while international nodes return real IPs, the block is confirmed even though you are testing from abroad.
Will the block affect my server-side code?
It depends on where your server is hosted. If your backend runs on a cloud provider like AWS, Vercel, or Railway with servers outside India, it can reach Supabase directly since the block only applies to Indian ISP networks. However, if your server is hosted in India or routes through an Indian ISP, it will be affected. Client-side code running in users' browsers in India is always affected since it goes through their local ISP.
How do I monitor for future blocks?
Set up an uptime monitoring service (like UptimeRobot or Better Stack) that checks your Supabase endpoint from an Indian server. Configure it to alert you if the endpoint becomes unreachable. Alternatively, using a reverse proxy like JioBase makes your app immune to future DNS blocks since traffic flows through an unblocked domain regardless of what ISPs do.

Fix your blocked app in under 60 seconds

Now that you have confirmed the block, fix it. Deploy your own proxy and get your Supabase-powered app working for every user in India. One command is all it takes.

npx create-jiobase — self-host on Cloudflare Workers for free

Free tier includes 1 proxy app and 50,000 requests/month. No credit card required.

Sunith VS

Written and verified by

Sunith VS

Building tools that help Indian developers ship without ISP interference. Creator of JioBase.