Occasionally Miro functions may have trouble performing when Miro is not allowed access. This can happen due to issues or limitations applied to your network connection or environment that you use. The following article lists the most common causes of such issues.
The Miro application - specifically the board pages - requires WebSocket connections. If you're having issues opening your boards but the dashboard and the settings pages open as expected this might mean that your connection does not support WebSockets.
To test your connection, please open this website.
If the Websockets are identified, you'll see the following message:
If the result is different, it's most likely that there's something in your network that blocks WebSocket connections. If this is the case try the following:
- Using a different network connection
- Using a VPN
- If you use a corporate connection contact your network administrator and ask them to enable the WebSocket connections on port 80 and 443 (SSL). They might be closed or filtered within your corporate network for security reasons. In order to establish a connection, these ports should be open for Miro addresses to access (see addresses in the "If you use a Firewall" section below).
If the Websockets are identified correctly but there are still issues establishing the connection, please contact Miro Support.
If you use a Firewall
You will need to add our static IP addresses to the whitelist as well. Note that the IP addresses are used only to reach out to the Atlassian systems in regard to the Jira-related integrations we have. Miro application IP addresses are dynamic.
If you use a proxy
Please ensure that you provide Miro with a by-pass. The following specifications will help.
- The proxy server must support WebSocket connections (HTTP/2).
- The proxy HTTP version should be set as 1.1.
- Source IP/host: see the NAT IPs above (used for Atlassian integrations only).
- Source port: 80. 80 is used for users that access Miro through HTTP to direct them to HTTPS (blocking 80 is not recommended).
- Destination port: 443 (SSL). 443 is used for HTTPS.
- Protocol: HTTPS
- TLS: 1.2. (We’re hosted in AWS and use AWS Security Policies. When AWS and all our plugin partners start supporting 1.3. we will be able to migrate as well).
- The timeout value on the proxy server should be prolonged. It is most likely that your system waits around 60-90 seconds to connect. It would be best to prolong it to 120-180 seconds.
- The proxy server should not truncate the request and response headers. Please check if the Upgrade and Connection headers are proxied by the client.
Here is an article with more information on the mailers you need to whitelist.