Calxa uses two secure domains to deliver the full application experience. If one of these connections is blocked or modified by your network, some features may not work as expected.
Domains Calxa Uses
cloud.calxa.com
This domain is responsible for:
The main Calxa web application
Loading dashboards and general navigation
API requests to backend
This domain must be reachable over standard HTTPS.
https://cloud.calxa.com
login.calxa.com
This domain is responsible for:
User authentication
Multi‑factor authentication
Password resets and account recovery
Redirecting you back to Calxa once sign‑in is complete
This domain must be reachable over standard HTTPS.
https://login.calxa.com
internal.calxa.com
This domain is responsible for:
Real‑time communication
Handling long running tasks and processes
Generating reports
Organisation sync
Data imports
Notifications and other background task updates
This connection uses WebSockets over WSS (encrypted, similar to HTTPS).
This domain must therefore be reachable over standard HTTPS and WSS.
https://internal.calxa.com
wss://internal.calxa.com
Troubleshooting Steps (for IT Teams)
Tip 💡blocks or re-writes over wss://internal.calxa.com is the most common error
Even when the firewall appears to allow the domain, WebSocket traffic can still be blocked or altered by:
Antivirus or endpoint protection (e.g., Datto Antivirus, Web Shield, HTTPS scanning)
SSL/HTTPS inspection
Transparent proxies
Content filtering or traffic‑inspection layers
VPNs or corporate network routing rules
These tools may not show a “block” in logs — instead, they silently interrupt or rewrite the WebSocket handshake.
1. Confirm the basics
Ensure the user has an active internet connection
Test in another browser (Chrome, Edge)
Try from a different network (mobile hotspot) to isolate local network effects
Try from an alternate device (another PC) to isolate the devices settings
2. Check antivirus / endpoint protection
Look for:
Real‑time protection events
Web protection / safe browsing logs
HTTPS scanning or certificate rewriting
Blocked or modified WebSocket traffic
3. Check for SSL/HTTPS inspection
WebSockets over wss: will fail if:
Certificates are being intercepted
Traffic is being decrypted and re‑encrypted
The inspection layer doesn’t support WebSockets properly
4. Confirm firewall and proxy behaviour
Even if rules appear open, verify:
No transparent proxy is rewriting headers
No content filter is modifying the request
WebSocket upgrades (HTTP 101 Switching Protocols) are allowed end‑to‑end
Testing WebSockets with Browser Developer Tools
Chrome / Edge
Open Developer Tools (F12)
Go to the Network tab
At the top, you’ll see a row of filters: All Fetch/XHR JS CSS Img Media etc....
Click Socket or WS — this filters the list to only WebSocket connections
Reload the Calxa page while DevTools is open
You should see an entry for something like:
NotificationHub?id=....OrganisationUpdateHub?id=...
ReportingStatusHub?id=...Click it to see:
Headers (including the WebSocket upgrade request)
Status Code (e.g., “101 Switching Protocols”, “200 OK”, “pending”)
Messages (messages sent/received)
What you're looking for?
If the WebSocket connection:
never appears -> something is blocking the request before it reaches the browser
shows “empty” or “failed”
The browser never received an HTTP response
Something blocked or intercepted the request before it reached the server
appears but status “200 OK” or “Pending”
Select the Messages tab
If you see {"error":"Handshake was canceled."} a proxy or antivirus is interfering
shows “101 Switching Protocols”
Connection succeeded
This is one of the quickest ways to confirm whether the issue is local, network‑level, or endpoint‑security‑related.