Network Requirements

Occasionally Dotwork functions may have trouble performing when Dotwork is not allowed access. This can happen due to issues or limitations applied to your network connection or the environment that you use.

Dotwork relies on modern, stable network connections. If you can sign in and navigate settings but experience issues loading content (for example images, fields, or requiring refreshes), your network may be restricting one or more of the technologies we use.

The following article lists the most common causes of such issues.

1. WebSocket Connectivity

Dotwork’s live updates and interactions all require outbound WebSocket connections over port 443.

If you suspect WebSockets are blocked, try the following:

• Switch to a different network such as a mobile hotspot.
• Disable or re-configure your VPN or secure web gateway.
• Ask your IT team to allow outbound WebSocket traffic, and wss:// on port 443.
• Ensure Dotwork domains are not blocked (see section 3).

2. If you use a proxy or firewall

If your organization uses a firewall or secure web gateway, confirm that Dotwork domains and services are allow-listed. Dotwork’s core infrastructure is hosted on AWS and uses dynamic IP addresses, so we recommend allowing traffic by domain rather than by IP.

Please ensure that you provide Dotwork with a by-pass. The following specifications will help.

• The proxy server must support HTTP connections over HTTP/2 on port 443. HTTP/1.1 is accepted but materially degrades performance.
• The proxy server must support gRPC-Web or gRPC connections over HTTP/2 on port 443. gRPC mandates HTTP/2; gRPC-Web can fall back to HTTP/1.1.
• The proxy server must support WebSocket connections over HTTP/1.1 on port 443. WebSockets are the one exception to the HTTP/2 requirement above — see the note below.
• The proxy HTTP version should be set to 2 for HTTP and gRPC/gRPC-Web traffic, and 1.1 for WebSocket traffic.
• If your proxy performs SSL inspection, it must negotiate HTTP/2 via ALPN (h2) and pass the connection through, rather than terminating it and re-originating it as HTTP/1.1.
• Browser destination ports: 443 using HTTPS protocol.
• TLS: 1.2 and 1.3. (Dotwork uses AWS Security Policy ELBSecurityPolicy-TLS13-1-2-2021-06 for protocols and ciphers. We will migrate to TLS 1.3 once fully supported.)
• Increase proxy idle/handshake timeouts to 120–180 seconds.
• Increase proxy per request timeout to 60 seconds.
• Ensure the proxy does not strip Upgrade or Connection headers. These are required for WebSocket connections, which use HTTP/1.1.
• For third party integrations different network allowances will be needed.

Why HTTP/2 matters: browsers cap themselves at roughly six concurrent connections per origin on HTTP/1.1, while HTTP/2 multiplexes an unlimited number of requests over a single connection. A Dotwork view issues around 50 requests, so on HTTP/1.1 what should be one round of requests becomes eight or more sequential rounds, each waiting on its slowest member. Dotwork’s load balancer already has HTTP/2 enabled and negotiates it with any client that offers it, so the downgrade almost always happens at an inspecting proxy in the network path.

Note on WebSockets: the HTTP/2 requirement above applies to HTTP and gRPC/gRPC-Web traffic only. WebSockets over HTTP/2 require RFC 8441 Extended CONNECT, which most inspecting proxies do not implement, so Dotwork’s WebSocket connections still use HTTP/1.1 with the standard Upgrade handshake. Do not apply the HTTP/2 setting to WebSocket traffic.

3. Dotwork Domains Allowlist

In secure environments you must permit access to all Dotwork domains for the application to function correctly.

After reviewing the steps above, if you still experience connectivity problems please contact our support team at support@dotwork.com. We’re here to help.