Supabase ERR_CONNECTION_TIMED_OUT in India: What It Means and How to Fix It

What ERR_CONNECTION_TIMED_OUT means

ERR_CONNECTION_TIMED_OUT means your browser (or app) tried to establish a TCP connection to a server and received no response within the timeout window. The request was sent, but nobody answered.

This is different from a ERR_CONNECTION_REFUSED (the server actively rejected the connection) or a ERR_NAME_NOT_RESOLVED (DNS lookup failed entirely). With a timeout, DNS resolved to some IP address, but that IP either does not exist, is unreachable, or is deliberately dropping packets.

In the case of Supabase in India, the timeout happens because your ISP's DNS resolver returns a sinkhole IP address instead of Supabase's real server. Your browser connects to the sinkhole, which silently drops the connection.

Why this happens in India

Indian ISPs including Jio, Airtel, and ACT Fibernet are DNS-poisoning all *.supabase.co domains. When your app tries to resolve a Supabase domain, the ISP intercepts the DNS query and returns a fake IP address.

Here is what the normal flow looks like versus the blocked flow:

NORMAL FLOW (outside India / unblocked ISP):

  Browser                ISP DNS              Supabase
    |                      |                     |
    |--- DNS query -------->|                     |
    |    abcd.supabase.co  |                     |
    |                      |                     |
    |<-- Real IP ----------|                     |
    |    104.18.x.x        |                     |
    |                      |                     |
    |--- HTTPS request --------------------------->|
    |                                             |
    |<-- 200 OK ----------------------------------|


BLOCKED FLOW (Jio / Airtel / ACT in India):

  Browser                ISP DNS              Sinkhole    Supabase
    |                      |                     |            |
    |--- DNS query -------->|                     |            |
    |    abcd.supabase.co  |                     |            |
    |                      |                     |            |
    |<-- Fake IP ----------|                     |            |
    |    49.44.x.x         |                     |            |
    |                      |                     |            |
    |--- HTTPS request -------->|                |            |
    |                           |  (drops)       |            |
    |                           |                |            |
    |... waiting ...            |                |            |
    |... waiting ...            |                |            |
    |                           |                |            |
    X  ERR_CONNECTION_TIMED_OUT |                |            |

The ISP never lets your request reach Supabase. It silently redirects you to a dead-end IP, and your connection hangs until the browser gives up.

How to confirm it is an ISP block

Run these commands from your terminal to diagnose the issue:

Step 1: Check what IP your DNS returns

# Using your ISP's DNS (likely poisoned):
$ nslookup yourproject.supabase.co
Server:   198.18.0.1
Address:  198.18.0.1#53

Name:     yourproject.supabase.co
Address:  49.44.79.236  # Sinkhole IP - NOT Supabase

# Using Cloudflare DNS (should return real IP):
$ nslookup yourproject.supabase.co 1.1.1.1
Server:   1.1.1.1
Address:  1.1.1.1#53

Name:     yourproject.supabase.co
Address:  104.18.x.x   # Real Supabase IP

If the two lookups return different IPs, your ISP is poisoning DNS for Supabase domains.

Step 2: Test connectivity with curl

# This will time out on blocked ISPs:
$ curl -v --max-time 10 https://yourproject.supabase.co/rest/v1/
* Connection timed out after 10001 milliseconds
curl: (28) Connection timed out

# Force curl to use the real IP via Cloudflare DNS:
$ curl -v --max-time 10 --resolve yourproject.supabase.co:443:104.18.x.x \
  https://yourproject.supabase.co/rest/v1/
HTTP/2 200 # Works when bypassing ISP DNS

If curl times out normally but works when you force the real IP, the block is confirmed. Your ISP is intercepting DNS queries for *.supabase.co.

Quick test: try a different network

The fastest way to confirm it is an ISP block: connect to a different network and try again.

The wrong fixes

These workarounds appear in every forum thread but none of them solve the problem for production apps:

The right fix: reverse proxy

The solution is to route your Supabase traffic through a domain that is not blocked. A reverse proxy on Cloudflare's edge network receives your requests on an unblocked domain and forwards them to Supabase on the server side, where there is no ISP block.

JioBase is a managed reverse proxy built specifically for this. Set it up in three steps:

Code example: before and after

Before (times out on Indian ISPs):

import { createClient } from '@supabase/supabase-js'

const supabase = createClient(
  'https://abcdefgh.supabase.co',
  process.env.SUPABASE_ANON_KEY
)

After (works everywhere):

import { createClient } from '@supabase/supabase-js'

const supabase = createClient(
  'https://myapp.jiobase.com',    // proxy URL
  process.env.SUPABASE_ANON_KEY   // same key
)

Technical details: how the proxy works

JioBase runs as a Cloudflare Worker deployed across 300+ edge locations worldwide. When a request arrives:

1. 1 Your user's browser resolves myapp.jiobase.com using their ISP's DNS. Since jiobase.com is not blocked, this resolves to a Cloudflare IP normally.
2. 2 The HTTPS request hits the nearest Cloudflare edge node. The Worker looks up which Supabase project is mapped to this slug.
3. 3 The Worker rewrites the URL from myapp.jiobase.com/rest/v1/... to abcdefgh.supabase.co/rest/v1/... and forwards the request server-side.
4. 4 Cloudflare's servers are not subject to Indian ISP DNS blocks. The request reaches Supabase normally.
5. 5 The response flows back through Cloudflare to the user. Total added latency: 1-5ms.

For WebSocket connections (Supabase Realtime), the Worker performs a WebSocket upgrade and maintains a persistent bidirectional connection between the client and Supabase, proxying frames in both directions.

Frequently Asked Questions