Team: Huntress Managed Endpoint Detection and Response (EDR)
Product: Your sites firewall, router, DNS, PSA, and/or content filtering platforms
Environment: Huntress Management Portal
Summary: Any firewall that restricts port 443 outbound will need to add these URL's to their exclusion / allow list in order for the Huntress agents to communicate securely with the Huntress.io portal. These are not static IP addresses or FQDNs but are set by AWS and should be added to your DNS and content filter tools. Additionally if you're configuring a self-hosted ticketing system (PSA aka Professional Services Automation) you may need to open up communication. Finally you may notice Huntress "taking" a high number port occasionally, read on for more information.
Huntress is not compatible with most proxy servers. If you can allow/exclusion list the Huntress.io certificate and all Huntress communication you might be able to get the communication working. We cannot provide support for agents unable to communicate because of proxy servers.
Testing Scripts are available in this article.
Agent communication
PSA communication (self hosted)
Active port considerations
Agent Communication
What are the IP addresses/ranges that should be allowed endpoints to communicate with huntress.io?
We utilize a fully scalable infrastructure within the Amazon Web Services (AWS) and Microsoft Azure platforms paired with Cloudflare storage. In order to maintain redundant connectivity and allow for failover, there are no static IP addresses or FQDNs.
If you restrict outbound traffic, you will need to allow outbound communication to the following over port 443:
- *.huntress.io
- *.huntresscdn.com
- huntress-*.s3.amazonaws.com
- *.bugsnag.com (this is for our bug reporting software if an Agent has an issue communicating) (you may see it point to something like
6.205.186.35.bc.googleusercontent.com) - huntress*.blob.core.windows
- raw.githubusercontent.com/huntresslabs/*
(bolded entries are new as of December 2025)
Note: some brands like Fortigate don't include the root domain as part of the wildcard so you may need to manually add huntress.io and huntresscdn.com when using wildcards.
Warning! Infix wildcards could allow for unintended communications to unauthorized domains. This isn't a security risk for the Huntress agent or portal (our communication is entirely encrypted), however businesses with strict outgoing communication policies may wish to implement the list below without wildcards.
- update.huntress.io
- huntress.io
- eetee.huntress.io
- eetee.huntresscdn.com
- huntresscdn.com
- huntress-installers.s3.amazonaws.com
- huntress-updates.s3.amazonaws.com
- huntress-installers.s3.us-east-1.amazonaws.com
- huntress-uploads.s3.us-west-2.amazonaws.com
- huntress-user-uploads.s3.amazonaws.com
- huntress-rio.s3.amazonaws.com
- huntress-survey-results.s3.amazonaws.com
- notify.bugsnag.com
- sessions.bugsnag.com
- huntress-log-uploads.s3.amazonaws.com
- agent.huntress.io
- huntressedrue2.blob.core.windows.net
- huntresssiemue2.blob.core.windows.net
- raw.githubusercontent.com/huntresslabs/
For accounts with Host Isolation enabled where the site's DC is also the DNS server, it may be necessary for the Huntress agent to fall back on CloudFlare's public DNS, thus 1.1.1.1:53/udp should also be added to allowed outbound traffic. Normal operation of the agent does not require communication with this IP, this is strictly for Host Isolation events where the DNS server could be isolated. We do also have a connectivity check for Cloudflare on port 80 to determine whether the fallback DNS is available. See this article for more details.
PSA and SIEM Communication
These IP addresses are the source for all outbound traffic from the Huntress to your systems, including both self-hosted PSA communication and SIEM data from API-based sources (does not affect local syslog, OS log files, or HEC SIEM sources).
Ensure the following IP addresses have been allow listed in the applicable PSA or API SIEM source for this purpose:
52.4.130.244
34.205.224.75
184.72.103.99
107.21.187.4
Huntress is in the process of moving its applications from AWS to Azure, which is going to add IP's to our cloud. For this first move this will only affect IP's that Huntress uses to send data to your systems. If you have setup an allow list on your PSA or SIEM (API sources only) source systems you'll need to add these addresses (don't remove the above IP's yet!):
4.150.82.176/28
172.200.220.176/28
Please note that these are CIDR blocks of 16 addresses each, not a single address.
Active port considerations
It's quite rare but occasionally you might run into issues where Huntress is "taking" ownership of a listening port which might interfere with another program (usually a hosting/dev app like Visual Studio/IIS/etc). These high numerical-value port's are randomized, temporary, and uncontrollable.
Windows: You can verify which ports Huntress is currently using by running this PoweShell command:
Get-NetTcpConnection | Select Local*,Remote*,State,@{Name="Process";Expression={(Get-Process -Id $_.OwningProcess).ProcessName}} | Where-Object{$_.Process -eq "HuntressAgent"}
macOS: You can verify which ports Huntress is currently using by running this terminal command:
sudo lsof -i -P | grep "Huntress"
Linux: You can verify which ports Huntress is currently using by running this terminal command:
sudo netstat -lp | grep "huntress"