Allow Guance synthetic monitoring through a cloud firewall

Use verified probe source addresses, protocols, and ports to allow synthetic checks through DigitalOcean Cloud Firewalls and diagnose remaining failures.

Best practices
Illustration of application infrastructure and operations

A service that works locally but fails an external synthetic check is not necessarily down. Compare the failing node, timestamp, and error first. Use available host-firewall, WAF, and application evidence to investigate blocking; a timeout alone is not a reason to broaden every inbound rule.

DigitalOcean Cloud Firewalls do not provide traffic logs. Do not rely on finding a blocked-packet log in that product when following the steps below.

Identify the probe source and destination

Guance supports API checks including HTTP, TCP, ICMP, and WebSocket. Confirm the selected nodes, destination address, port, and protocol in the task, then obtain the current egress addresses from node information or official support. For a self-hosted node, verify the address after any outbound NAT.

A browser's client address, a server's private IP, or an outdated probe list is not a substitute for the probe's actual egress IP. This guide deliberately avoids a static IP list because nodes can change.

Add a DigitalOcean inbound rule

In Networking → Firewalls, open the firewall associated with the destination Droplet. Configure only what the check requires:

Field Configuration
Source Verified probe IP addresses or CIDR ranges
Protocol TCP for HTTP/HTTPS and TCP checks; a separate ICMP rule for ICMP checks
Destination port The actual service port, such as 443 for HTTPS
Applied resources The correct Droplet or resource tag

Save the rule and check the next scheduled result. Correlate it with application logs and any available host-firewall or WAF logs. Review all applicable firewalls: a matching deny rule overrides an allow rule, even across firewalls on the same Droplet. Other allow rules can broaden access where no deny rule applies.

Investigate checks that still fail

  1. Connection timeout: verify source addresses, ports, routes, and both cloud and host firewalls.
  2. Connection refused: inspect the service listener and binding; explicit reject rules are another possibility.
  3. TLS handshake failure: check the certificate, hostname, and protocol. Allowing packets will not repair a certificate error.
  4. HTTP 403 or a challenge page: inspect WAF/CDN rule matches. Limit any exception to confirmed probe sources and required paths.
  5. Only some nodes fail: compare regions and networks before concluding that the destination blocks every failing probe.

When a CDN fronts the service, the origin may see CDN egress addresses rather than probe addresses. Evaluate origin firewall rules and edge WAF rules separately.

Keep the access boundary narrow

An allowlisted source is not permission to bypass application authentication or other request checks. Open only the ports and paths the task needs. Monitoring probes do not need SSH or Remote Desktop access merely to check a website. Review node changes periodically and remove obsolete exceptions.

References

Get a tailored plan

Contact us

Join the community

Scan with WeChat
to join the community

Try Guance

Start online and pay only for what you use.

Get started

Choose a Guance plan

Code hosting