Tasks Device Compatibility

Network Access Permissions

What enterprise IT teams must allow through firewalls, proxies, and content filters so candidates on corporate networks can take TestInvite exams: the domain allowlist, protocol notes, and common pitfalls like SSL inspection and blocked WebSockets.

Updated 2026/07/13

Candidates taking exams from a corporate network — behind firewalls, web proxies, or content filters — need a small set of domains reachable. If your organization restricts outbound traffic, share this list with your IT team before exam day.

Domains to allow

All traffic is HTTPS on the standard port 443 — no special ports are required.

DomainPurpose
*.testinvite.comThe exam application and all TestInvite API calls
*.googleapis.comCore infrastructure: real-time exam data, sign-in, and upload/download of all media (webcam photos, video chunks, screen recordings, recorded answers, question media)
*.firebaseapp.comAuthentication service
*.firebaseio.comReal-time connection — uses WebSockets (wss://), which must not be blocked or downgraded
*.gstatic.comStatic resources (fonts, security scripts)
www.google.comreCAPTCHA — part of TestInvite's abuse-protection layer; if blocked, requests to the platform are rejected

Conditional domains

DomainNeeded when
*.youtube.com, *.ytimg.comThe test content embeds YouTube videos
*.stripe.comExam access requires payment
External media hostsContent authors linked externally hosted images, audio, or video in questions
To keep the allowlist minimal, host all assessment media on TestInvite (upload images, audio, and video into the content editor) rather than linking external URLs. Externally hosted content adds unpredictable domains to the list and is the most common cause of “the question doesn't load” reports from restricted networks.

Common pitfalls on managed networks

  • SSL inspection (TLS interception) — proxies that decrypt and re-encrypt HTTPS traffic can break the real-time data stream and the reCAPTCHA security verification, producing hard-to-diagnose failures. Exempt the domains above from inspection.
  • Blocked WebSockets — some proxies silently drop wss:// connections. The real-time layer has an HTTPS fallback, but allowing WebSockets gives the most reliable experience.
  • Upload size or rate limits — proctored exams continuously upload webcam and screen material (see the Internet Connection section). Proxies that throttle or buffer uploads can starve the monitoring stream.
  • Device policies blocking camera and microphone — for proctored exams, the browser must be allowed to access the webcam and microphone. Enterprise device management that disables camera access at the OS level blocks candidates at the pre-start checks regardless of network settings.
  • VPNs — corporate VPNs that route traffic through distant gateways add latency and can trip rate protections. Where policy allows, exempt exam traffic from the VPN.

Verify before exam day

The pre-start checks validate connectivity end to end — including a real upload to the media storage — before the exam begins. Run a short trial exam from the actual candidate network, with the same device profile and the same proctoring settings as the real exam, and have IT watch for blocked requests. Five minutes of verification prevents exam-day escalations.

Go back