How to whitelist Kite IPs on a corporate network
Zerodha Kite is a browser-based and mobile trading platform that communicates with Zerodha’s servers over HTTPS and WebSocket connections. Corporate networks often block non-business web traffic through firewalls, web proxies, or URL filtering systems. If Kite is inaccessible or partially functional on a corporate network, the likely cause is that one or more required domains or connection types are blocked.
This guide is addressed to both individual users who want to request a firewall change from their IT department and to IT administrators implementing the whitelist.
Conflict-of-interest disclosure. This guide is published by WebNotes Editorial Team for informational purposes only. WebNotes has no commercial relationship with Zerodha or Cloudflare. Individual employees must ensure their employer’s acceptable-use policy permits personal trading on corporate networks.
Prerequisites
- Administrative access to the corporate firewall or proxy, or the ability to submit a change request to your IT department.
- Your employer’s acceptable-use policy allows personal trading on the corporate network.
- An active Zerodha account.
Step 1: Diagnose what is being blocked
Different symptoms indicate different blocked components. Identifying the specific failure narrows the scope of the whitelist change required.
| Symptom | Likely blocked component |
|---|---|
| Kite login page does not load | kite.zerodha.com is DNS-blocked or TLS-intercepted |
| Login page loads but login fails | zerodha.com authentication API is blocked |
| Login succeeds but market watch shows static prices | WebSocket connections (wss://) are blocked |
| Orders fail to submit | Order placement API endpoint is blocked |
| Charts do not load | Charting data endpoint or static asset CDN is blocked |
| Two-factor authentication page does not load | An intermediate domain in the login flow is blocked |
Use the browser’s developer tools (F12 → Network tab) to inspect which requests are failing. Failed requests show a status of “blocked,” “CORS error,” or connection-reset errors.
Step 2: Obtain the current domain list from Zerodha
Zerodha does not publish a permanent, versioned list of all IP addresses used by Kite in its public documentation, because IP addresses may change as infrastructure is updated. The most reliable approach is:
- Contact Zerodha support and request the “list of domains and IP ranges required for Kite on restricted corporate networks.”
- Zerodha’s support team can provide the current list, which may include domains in addition to the primary kite.zerodha.com.
While waiting for the official list, the following domains are generally required based on Kite’s architecture (this is not an exhaustive or authoritative list; verify with Zerodha support before submitting to IT):
| Domain | Purpose |
|---|---|
| kite.zerodha.com | Main trading platform (web) |
| api.kite.trade | Kite Connect API (if using programmatic access) |
| zerodha.com | Authentication and account services |
| console.zerodha.com | Console (portfolio and reports) |
| s.kite.trade | Static assets and charting data |
| ws.zerodha.com or wss.kite.trade | WebSocket streaming for live quotes |
| fonts.googleapis.com | Web fonts (may be independently accessible) |
| *.cloudflare.com | Cloudflare CDN (if Cloudflare-fronted content is blocked) |
Zerodha uses Cloudflare as its CDN and DDoS protection provider. If your corporate proxy blocks Cloudflare IP ranges, a broad set of Zerodha resources may be unreachable.
Step 3: Draft the whitelist request for your IT administrator
Prepare a written request for your IT team with the following information:
Business justification. State that you require access to Zerodha Kite for personal investment management (or as appropriate to your circumstances) and that the trading platform is time-critical (live market data, order submission).
Domain list. Provide the domains from Step 2.
Port and protocol requirements.
| Protocol | Port | Purpose |
|---|---|---|
| HTTPS | 443 | All web traffic (login, order placement, data) |
| WSS (WebSocket over TLS) | 443 | Real-time market data streaming |
| HTTP | 80 | Redirect to HTTPS only; no sensitive data |
IP ranges. If your corporate firewall operates on IP-based allow lists (not domain-based), the relevant IP ranges are those used by Cloudflare (published at cloudflare.com/ips) plus any Zerodha-specific IP ranges provided by Zerodha support.
Proxy compatibility. If your corporate network routes all traffic through an HTTP proxy, confirm with Zerodha support whether Kite’s WebSocket connections are compatible with HTTP CONNECT proxying. Some WebSocket implementations do not work reliably through HTTP proxies. If they do not, the IT team may need to create a bypass rule for Zerodha domains that allows direct TLS connections.
Step 4: Test Kite functionality after whitelisting
After your IT administrator applies the whitelist, perform the following tests in sequence:
Login. Open kite.zerodha.com and log in with client ID, password, and 2FA. A successful login confirms DNS resolution and HTTPS access are working.
Live quotes. On the Kite market watch, check whether prices are updating in real time during market hours. Static prices (not changing despite market activity) indicate WebSocket connections are still blocked.
Order placement. During market hours, place a limit order at a price well away from the market (a limit buy order far below the current price). If the order appears in the Orders tab as “Open,” the order placement API is working.
Charts. Open a stock chart on Kite. If historical and real-time candles load correctly, the charting data API and CDN are accessible.
If any test fails, note the specific symptom and return to Step 1 to narrow down the remaining blocked component, then update the whitelist request accordingly.
Troubleshooting
IT team has whitelisted the domain but Kite still does not work. HTTPS inspection (SSL/TLS decryption) by the corporate proxy can break WebSocket connections. Ask IT whether the proxy performs SSL inspection on Zerodha domains. If it does, request that SSL inspection be bypassed for *.zerodha.com and *.kite.trade.
Some Kite features work but live quotes are static. WebSocket upgrade requests may be blocked by a proxy that allows HTTP but not WSS. The proxy needs to allow WebSocket CONNECT tunnelling on port 443 for Zerodha’s WebSocket hosts.
Kite works on mobile data but not on the corporate Wi-Fi. This confirms the corporate network (not the Zerodha platform) is the source of the restriction. The mobile data connection bypasses the corporate firewall.
VPN usage. If your company issues a VPN and you are required to use it, Kite may route through the VPN’s network. In this case, the VPN’s firewall applies instead of the local network’s. Request the whitelist changes at the VPN level rather than (or in addition to) the local network.
Using the Kite mobile app as an alternative
While waiting for the corporate whitelist to be configured, the Kite mobile app on a smartphone connected to mobile data (not the corporate Wi-Fi) provides full platform functionality without any corporate network dependency. Personal mobile data use for trading is not subject to the corporate firewall.
Escalation path
For network-related issues that are confirmed to be on the Zerodha side (platform outage rather than corporate block), check the Kite status page at status.zerodha.com. For persistent platform issues not attributable to the corporate network, raise a support ticket at support.zerodha.com.
Related guides
References
- Zerodha Support, “Kite not loading on corporate network, domain whitelist,” support.zerodha.com.
- Cloudflare, “Cloudflare IP Ranges,” cloudflare.com/ips.
- IETF RFC 6455, “The WebSocket Protocol,” 2011.
- Zerodha Z-Connect Blog, “Kite architecture overview,” zerodha.com/z-connect.