> ## Documentation Index
> Fetch the complete documentation index at: https://docs.visiqlabs.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Network requirements for the Deployed Sensor

> The hosts a Deployed Sensor must reach, how the Windows sensor finds the proxy your network uses, and where a device records why it cannot reach VisIQ.

The Deployed Sensor reaches VisIQ over HTTPS from each device. It sends its scan reports, checks for and downloads new releases, and, where the Context Firewall proxy runs, enrols and fetches its rules. This page lists the hosts to allow, explains how the Windows sensor finds the proxy your network uses, and shows where a device records why it cannot reach VisIQ.

***

## Hosts to allow

Allow outbound HTTPS on port 443 from each device to both hosts.

| Host | Port | What the sensor uses it for |
| - | - | - |
| `api.visiqlabs.com` | 443 | Scan report, version check, download locator, enrolment, heartbeat, rules and decisions |
| `downloads.visiqlabs.com` | 443 | Signed sensor binaries for update and self-heal, and the browser extension package |

If your sensors report to an endpoint other than `https://api.visiqlabs.com`, allow that endpoint's host in place of `api.visiqlabs.com`. `downloads.visiqlabs.com` is read-only and serves only signed release builds, each at a fixed address for its version.

<Note>
  Since 8 October 2026, devices whose sensors report to `https://api.visiqlabs.com` download the sensor binaries for update and self-heal and the browser extension package from `downloads.visiqlabs.com`, and no longer need `visiq-edr-discovery-binaries.s3.us-east-1.amazonaws.com` for those downloads.

  The Windows package that **Download install.intunewin** builds for your tenant still comes from `visiq-edr-discovery-binaries.s3.us-east-1.amazonaws.com`. It downloads in the browser of the admin who presses the button, not on a device, so allow that host from the browsers of the admins who download packages.

  A deployment that runs its own VisIQ API serves these files from its own object store: the Windows package always, and the sensor binaries and the extension package unless it has set a download host of its own. Allow that object store's host, and the download host if it set one, in place of the hosts named here. The network checks on this page test only the API host your sensors report to and `downloads.visiqlabs.com`.
</Note>

### Only if your policy checks revocation

Windows may fetch certificate revocation data for the sensor's signing certificate from these hosts on port 80 when your policy checks signatures online. The sensor never calls them itself, and the network check does not test them.

| Host | Port |
| - | - |
| `ocsp.digicert.com` | 80 |
| `crl3.digicert.com` | 80 |
| `crl4.digicert.com` | 80 |

***

## How the Windows sensor reaches VisIQ

The sensor runs as SYSTEM. From version 0.3.107, in its default `auto` mode, it tries these routes in order for its own calls to VisIQ, and the first route that answers carries the call. The sensor then tries that route first for the next ten minutes.

1. **The proxy you name for the sensor**, with `install.ps1 -ProxyUrl` or the VisIQ policy key (see [Give the sensor your proxy](#give-the-sensor-your-proxy)).
2. **The machine WinHTTP proxy**, set with `netsh winhttp set proxy`, together with its bypass list.
3. **A PAC file or WPAD**, as the Windows proxy engine resolves it for the computer: WPAD auto-detection, a PAC URL that applies to the whole machine, or a PAC URL in the SYSTEM account's own Internet settings. The sensor asks Windows for the answer and never runs a PAC file itself.
4. **The proxy of a signed-in user's session**, on devices where the Context Firewall proxy runs. Its per-user task asks Windows how that user reaches VisIQ, and the sensor follows a recent answer.
5. **A machine-wide `HTTPS_PROXY` environment variable**, with its `NO_PROXY` exceptions.
6. **A direct connection**, last.

A route that fails at the proxy hands the call to the next route: the proxy does not answer, closes the connection, refuses the host, or asks for a sign-in the sensor cannot give. An answer from VisIQ itself, an error included, ends the call on the route that carried it. When two settings name the same proxy, the sensor tries it once.

<Note>
  To give the sensor a PAC file, make Internet Settings per-machine (the policy value `ProxySettingsPerUser` set to `0`) and set the PAC URL in the machine's connection settings, or answer WPAD auto-detection for the device. A PAC URL written only as the `AutoConfigURL` value under `HKLM\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings` is not applied to the SYSTEM account, so the sensor does not see it. Windows caches what WPAD auto-detection found; after you change WPAD, `netsh winhttp reset autoproxy` clears that cache.
</Note>

### Proxy sign-in and TLS

The sensor never sends a user name or password to a proxy and never stores a proxy credential. A user name or password written into a proxy address is ignored. When a proxy asks the sensor to sign in, it answers as the computer account with Negotiate (Kerberos), and with NTLM only when `AllowNtlm` is set to `1` in the policy key. Kerberos as the computer account needs a domain-joined or hybrid-joined device that can reach a domain controller, and a proxy that accepts computer accounts. Any other proxy that asks for a sign-in must let both hosts through without proxy authentication for the SYSTEM account.

Through a proxy, the sensor opens a tunnel and runs TLS to VisIQ inside it. If a gateway on the path inspects TLS, the sensor accepts the re-signed certificate only when the gateway's certificate authority is in the Local Machine trusted root store. Otherwise exempt both hosts from TLS inspection.

### Sensors before 0.3.107

Before version 0.3.107 the sensor reads neither the VisIQ proxy keys nor a PAC file or WPAD. Sensors 0.3.105 and 0.3.106 do follow a machine WinHTTP proxy, and earlier versions do not. On a device that still runs one of those, set the machine WinHTTP proxy so that the sensor can reach VisIQ and update itself.

***

## Give the sensor your proxy

When the computer already reaches the internet through a machine WinHTTP proxy, a PAC file that applies to the machine, or WPAD, the sensor follows it without a setting from you. Name a proxy for the sensor when the computer does not advertise the one it uses.

### On the install command

Append `-ProxyUrl` to the install command of the Win32 app:

```text theme={null}
powershell.exe -NoProfile -ExecutionPolicy Bypass -File install.ps1 -ProxyUrl http://proxy.example.com:8080
```

The value is `http://host` or `http://host:port`. A value that carries a user name, a password, a path or a space is ignored: the install prints a warning and carries on. The install records the proxy under `HKLM\SOFTWARE\VisIQ\Sensor` as `ProxyUrl`, with `ProxyMode` set to `explicit`, before the sensor's first scan. It writes through the 64-bit registry view, the one the sensor reads, although Intune runs the install in a 32-bit PowerShell.

In `explicit` mode the sensor uses that proxy and then a direct connection, and does not consult the computer's other proxy settings. A later install without `-ProxyUrl` leaves the recorded value in place. Uninstalling the sensor removes `HKLM\SOFTWARE\VisIQ\Sensor` and never touches the policy key.

### In the VisIQ policy key

To manage the sensor's proxy across a fleet without changing the install command, set these values under `HKLM\SOFTWARE\Policies\VisIQ\Sensor` with Group Policy or an Intune script:

| Value | Type | Meaning |
| - | - | - |
| `ProxyMode` | `REG_SZ` | `auto` (the default) tries the proxy in `ProxyUrl` first, then the computer's own proxy settings, then a direct connection. `explicit` tries the proxy in `ProxyUrl`, then a direct connection, and ignores the computer's other proxy settings. `direct` uses no proxy at all. |
| `ProxyUrl` | `REG_SZ` | `http://host:port`, with no user name or password. |
| `ProxyBypass` | `REG_SZ` | Hosts that go around the proxy in `ProxyUrl`, separated by semicolons, for example `*.visiqlabs.com`. |
| `AllowNtlm` | `REG_DWORD` | `1` lets the sensor answer a proxy's NTLM challenge as the computer account. The default is `0`. |

`explicit` without a usable `ProxyUrl` behaves as `auto`. Write the values in the 64-bit registry view: a 32-bit process, such as a script that Intune runs in a 32-bit PowerShell, otherwise writes them under `WOW6432Node`, where the sensor does not look. `reg add` with `/reg:64` writes the right view from either kind of process:

```text theme={null}
reg add "HKLM\SOFTWARE\Policies\VisIQ\Sensor" /v ProxyUrl /t REG_SZ /d http://proxy.example.com:8080 /reg:64 /f
```

### Which setting wins

Value by value, the policy key wins over the installer key that `-ProxyUrl` writes, so a `ProxyMode` set by policy applies to a `ProxyUrl` the install recorded. A `VISIQ_PROXY_URL` environment variable sets the proxy address over both keys; VisIQ support may ask you to set one for a test. The self-heal downloads the sensor again when it is missing, and it reads the same variable and keys, then the machine WinHTTP proxy.

***

## Read what a device records

### The install check

The install checks both hosts after it has verified the sensor and before it stops or replaces anything on the device. The check takes at most 60 seconds and never fails the install. It tests the route the sensor will take, through a proxy you name with `-ProxyUrl` on the same install command, and it checks the API host of your own deployment. It prints one line per host, a line with what to change when a host is blocked, and a result line, each starting with `VisIQ preflight:`. An install on a device with no route to the internet prints:

```text theme={null}
VisIQ preflight: api.visiqlabs.com BLOCKED (tcp-timeout)
VisIQ preflight: downloads.visiqlabs.com BLOCKED (tcp-timeout)
VisIQ preflight: The device has no network path to this host. If the network reaches the internet only through a proxy, give the sensor that proxy (install.ps1 -ProxyUrl, the VisIQ policy key, or the machine WinHTTP proxy), or allow this host for the SYSTEM account.
VisIQ preflight: result=attention route=none details=C:\ProgramData\VisIQ\discovery\preflight.json
```

A host that answers reads like `VisIQ preflight: api.visiqlabs.com ok via explicit(proxy.example.com:8080)`, with the route and the proxy that carried it. The result line says `result=ok` when both hosts answered and `result=attention` when one did not, and `route` names the route the check used for the API host. The same result is saved on the device in `C:\ProgramData\VisIQ\discovery\preflight.json`.

A package that carries a sensor before 0.3.107 is checked on the routes that build takes: the machine WinHTTP proxy, or a direct connection. When `-ProxyUrl`, the VisIQ policy key or `VISIQ_PROXY_URL` names a proxy, the check adds one line saying that this sensor build follows only the machine WinHTTP proxy and that those settings apply from sensor 0.3.107.

### The network record

Sensor 0.3.107 and later keep a record of how they reach VisIQ in `C:\ProgramData\VisIQ\egress-firewall\net-status.json`. Only SYSTEM and administrators can open it, and it never holds a key, a token or a proxy credential: a proxy appears only as host and port.

| Field | What it holds |
| - | - |
| `hosts` | One entry per host from the last network check: `ok`, the `reason` code and its `remedy`, the route (`path`) and the proxy (`via`) that carried the probe, and `attempts`, each route the check tried. |
| `outcomes` | The last scan report (`scan`), update (`update`) and Context Firewall proxy call (`proxy`), each with when it last ran (`at`), when it last succeeded (`succeededAt`) and its `reason` code. |
| `resolution` | What the sensor found for each route: the VisIQ proxy setting, the machine WinHTTP proxy and the PAC state. |
| `summary` | One line, for example `control blocked (tcp-timeout); download blocked (tcp-timeout)`. |

### The net-check command

Sensor 0.3.107 and later have a `net-check` command. It resolves the route exactly as the sensor does, tries every route to each host, and says what to change. In an elevated PowerShell on the device:

```powershell theme={null}
& "$env:ProgramData\VisIQ\discovery\visiq-discovery.exe" net-check
```

Each line starts with `VisIQ net-check:`. For a host that is blocked it lists every route it tried with that route's reason code, then what to change, and it ends with the proxy settings it found and a `result=` line like the install's. It exits 0 whatever it finds and updates `net-status.json`. Add `--json` to print the record as JSON, or `--no-write` to leave `net-status.json` unchanged.

The sensor runs as SYSTEM, and a check from your own prompt runs as you. Your account can have its own PAC or proxy settings, so to see what the sensor sees, run the check as SYSTEM.

***

## Reason codes

Every check names one of these reasons for each host. The same codes and sentences appear in the install output, in `net-check` and in `net-status.json`.

| Code | What happened | What to change |
| - | - | - |
| `ok` | Reachable. | Nothing. |
| `dns-fail` | The name did not resolve. | Let the device resolve this host name. A DNS filter or a resolver that does not forward public names is answering for it. |
| `tcp-timeout` | No TCP answer on port 443. | The device has no network path to this host. If the network reaches the internet only through a proxy, give the sensor that proxy (install.ps1 -ProxyUrl, the VisIQ policy key, or the machine WinHTTP proxy), or allow this host for the SYSTEM account. |
| `tcp-refused` | Connection refused. | Something on the path rejects connections to this host on port 443. Allow outbound HTTPS to it from the device or from the proxy. |
| `tcp-reset` | Connection reset. | A firewall or proxy closed the connection. Allow outbound HTTPS to this host, and check for TLS inspection on the path. |
| `proxy-unreachable` | The proxy cannot be reached. | The proxy the sensor was told to use does not answer. Check the proxy address and port, or remove the explicit setting so the sensor follows the machine proxy. |
| `proxy-timeout` | The proxy accepted the connection and did not answer. | The proxy is not forwarding this host. Allow it on the proxy for the SYSTEM account. |
| `proxy-closed` | The proxy closed the connection. | The proxy closed the connection instead of forwarding it, which is how many proxies refuse a host they require a sign-in for. Allow this host on the proxy for the SYSTEM account. |
| `proxy-denied` | The proxy refused the host. | The proxy's policy blocks this host. Add it to the proxy's allowlist for the SYSTEM account. |
| `proxy-auth-negotiate` | The proxy requires Windows authentication and the machine account could not provide it. | The sensor runs as SYSTEM and can only authenticate as the computer account. That needs a domain or hybrid-joined device that can reach a domain controller, and a proxy that accepts computer accounts. Otherwise exempt this host from proxy authentication for the SYSTEM account. |
| `proxy-auth-basic-ntlm` | The proxy requires a user name and password. | The sensor never sends a user password. Exempt this host from proxy authentication for the SYSTEM account, or allow the computer account. |
| `proxy-error` | The proxy returned an error. | The proxy answered with a server error. Check its health and its logs for this host. |
| `pac-fetch-failed` | The proxy auto-configuration file could not be used. | The PAC or WPAD address the machine is configured with did not load. Check that the SYSTEM account can fetch it, or set the proxy explicitly. |
| `tls-untrusted` | The certificate chain is not trusted. | A gateway on the path re-signs this host with a certificate authority the machine does not trust. Install that authority in the Local Machine trusted roots, or exempt this host from TLS inspection. |
| `tls-error` | The TLS handshake failed. | The TLS connection to this host failed. Check for TLS inspection or a protocol restriction (TLS 1.2 or later is required). |
| `http-401` | Reached the service, credential not accepted. | The network is fine. The sensor's key was rejected: it may have been revoked or replaced. Download a new package. |
| `http-403` | Reached a host that refused the request. | Something at or before this host refused the request. Check a web gateway or firewall policy that blocks this host. |
| `http-5xx` | The service returned an error. | The host answered with a server error. Try again later. |
| `timeout` | No answer in time. | The host did not answer in time. Check the path for a gateway that holds connections open. |
| `unknown` | Failed for a reason the sensor could not classify. | Run the net-check command on the device and send its output to VisIQ support. |

***

## When a device never reports

When a device has the sensor and VisIQ has received nothing from it, work through these steps in order.

1. **Check that Intune installed it.** Open the app in Intune and read **Device install status**. Devices install on their next check-in, so start with a device whose status reads Installed.
2. **Read the card in VisIQ.** The **Check that it arrived** step of the Deployed Sensor guide in Connectors says what VisIQ has received since your package was built. [What happens after the scan](/discovery/deployed-sensor#what-happens-after-the-scan) lists what each state means.
3. **Read what the device recorded.** `preflight.json` in `C:\ProgramData\VisIQ\discovery` holds the install check, and `net-status.json` in `C:\ProgramData\VisIQ\egress-firewall` the latest network check.
4. **Change what the reason code says.** [Reason codes](#reason-codes) gives the change for each code. A network that reaches the internet only through a proxy the computer does not advertise needs that proxy on the install command or in the policy key.
5. **Check the scan task.** In Task Scheduler, a last run result of `0x3` on the **VisIQ Discovery Sensor** task means that the scan ran and its report did not reach VisIQ. From version 0.3.112 the sensor sends a report that did not arrive again within the same run, for up to about 40 minutes, so a task shown as Running in that time is still trying. After that, the next scheduled scan or a restart sends a new report. Once you have made the change the reason code names, start the task to report without waiting.
6. **Check the sensor version.** `visiq-discovery.exe --version` in `C:\ProgramData\VisIQ\discovery` prints it. A sensor older than 0.3.107 does not read the VisIQ proxy keys, PAC files or WPAD: see [Sensors before 0.3.107](#sensors-before-0-3-107).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.