Overview

If your organization restricts outbound internet access, your IT or network administrator may need to configure the corporate firewall or gateway to allow UbiBot devices to upload data and users to access the UbiBot Console and website.

This guide provides domain, IP address, and port configuration information for the UbiBot Console Platform (ubibot.com). For on-premises deployments or custom integrations, use the network requirements specific to your deployment.

1. Domains, IP Addresses, and Ports

Allow outbound access to the following destinations according to your organization’s requirements. All ports in the table are TCP destination ports.

Ports 8083 and 8084 apply to the CDN hostname only if the deployed service supports connections on those ports. Otherwise, use the MQTT/WebSocket destination and port confirmed by UbiBot Technical Support.

Ports 80 and 443 are used for HTTP and HTTPS communication. The other listed ports are used for MQTT-related communication, depending on the endpoint configuration.

When configuring console access, allow both the console domain and its associated API endpoint. Allowing only console.ubibot.com may not be sufficient for data loading and other console functions.

For a least-privilege configuration, contact UbiBot Technical Support to confirm the domains and ports required for your specific device models and features.

2. Configuration Requirements and Recommendations

Allow Outbound Connections and Return Traffic

Device connections and browser requests are initiated from within your network. You generally do not need to open inbound service ports or configure port forwarding for standard device communication.

Ensure that return traffic for established connections is permitted. Stateful firewalls can track connections and allow their responses, while stateless access control lists require appropriate rules in both directions. “No inbound service ports required” does not mean that return traffic can be blocked.

Prefer Domain-Based Rules Where Supported

If your firewall supports fully qualified domain name (FQDN) rules, configure the domains and corresponding ports listed above. Confirm that the firewall updates its rules when DNS records change and that the selected rule type supports the required traffic. An HTTP/HTTPS application rule may not cover non-HTTP TCP connections.

Treat the listed IP addresses as references rather than a guaranteed, complete list of permanent destinations. CDN services may use shared infrastructure instead of dedicated server addresses, so a single IP address should not be treated as a unique identifier for a UbiBot service.

If your firewall supports only IP-based rules, obtain the current destination requirements from UbiBot Technical Support before deployment and review them when connectivity issues occur.

Ensure DNS Resolution Is Available

Devices and computers must be able to resolve the required UbiBot domains through your organization’s approved DNS servers.

For conventional DNS, permit the necessary DNS traffic to those servers, including UDP and TCP support. Apply these rules to your DNS servers—not to the UbiBot application servers listed above.

An IP allowlist does not replace DNS resolution. Allowlisting an address permits traffic to that destination; it does not enable a device to resolve a hostname when DNS is unavailable.

Check Proxy and WebSocket Support

If users access the console through a proxy server, ensure that the proxy permits the required domains and destination ports. Where WebSocket connections are used, the proxy must also support their connection establishment and subsequent bidirectional traffic.

For device connectivity, use direct outbound access unless proxy support has been confirmed for the specific device and firmware. Do not assume that a device supports HTTP proxies, SOCKS proxies, or proxy authentication; UbiBot’s published setup requirements for WS1 and WS1 Pro specify a network without a proxy server.

3. Frequently Asked Questions

Why must ports 80 and 443 be allowed for api.ubibot.com?

Devices may communicate with api.ubibot.com over HTTP or HTTPS in addition to MQTT-related connections. Blocking ports 80 and 443 can therefore interrupt device-to-platform communication, even when other required ports are accessible.

What is api-cdn.ubibot.com used for?

api-cdn.ubibot.com is the default API/CDN endpoint used by the console. Blocking this domain may prevent data from loading or make some console features unavailable, even when the console’s sign-in page opens successfully.

Allow this domain and the applicable service ports listed in the configuration table.

Why is communication still failing after ports 80 and 443 have been allowed?

Opening HTTP and HTTPS ports does not automatically permit every communication method. Check whether the affected device or feature requires additional MQTT-related connections and whether the firewall permits the corresponding destination, port, and application protocol. Network rules and application-level rules may handle these connections differently.

Compare the failure time with device logs and firewall records to identify the blocked connection. Do not assume that successfully opening the UbiBot website confirms device connectivity.

Does remote device control require inbound port forwarding?

Generally, no. For standard platform-based control, commands are delivered through communication initiated by the device rather than through a new, unsolicited connection from the internet.

Keep the required outbound connections and their return traffic available. Networks using stateless access controls must explicitly permit the necessary response traffic.

4. Configuration and Verification Checklist

After applying the firewall rules, verify device connectivity and console operation separately.

5. Technical Support

If connectivity issues persist, contact UbiBot Technical Support and provide the device model, firmware version, connection type, time of failure, and any displayed error messages.

Where available, include relevant device connection logs, DNS lookup results, and firewall or proxy records showing the destination address, port, and reason for blocking.

Remove passwords, API keys, access tokens, and other sensitive information before sharing logs or screenshots.