Service Detection
How Scanopy identifies services and what to do when detection fails.
Scanopy automatically identifies 200+ services during network discovery. This page explains how detection works and what to do when a service isn't detected.
For the complete list of detectable services and their match patterns, see scanopy.net/services.
Why Wasn't My Service Detected?
First: Check if the service is in Scanopy's detection list at scanopy.net/services. If it's not listed, you can request it.
If the service is supported but wasn't detected:
Service on non-standard port — Grafana on port 8080 instead of 3000? Scanopy won't probe port 8080 for Grafana's endpoint pattern. Move to the default port or manually add the service.
Service requires authentication — If a service returns 401/403 before Scanopy can read the response body, endpoint matching fails. Some services (like Plex) have patterns that account for this, but many don't.
Docker container not exposed — Containers on internal bridge networks aren't reachable via network scan. Use Docker discovery instead, which inspects the Docker API directly.
Firewall blocking the daemon — The daemon must be able to connect to the service's port. Check that firewall rules allow the daemon to probe the host.
How Detection Works
Detection happens in phases:
- Port scan — Find open TCP and UDP ports
- Endpoint probing — Send HTTP requests to known paths
- Pattern matching — Compare results against service definitions
Each service has a detection pattern that specifies what to look for. Patterns can include:
| Check | What It Does |
|---|---|
| Port | Is a specific port open? |
| Endpoint | Does the HTTP response body contain a string? |
| Header | Does an HTTP header contain a value? |
| MAC Vendor | Does the device's MAC address belong to a vendor? |
| Gateway | Is this IP in the daemon's routing table? |
Patterns can be combined with AllOf (all must match) or AnyOf (any can match).
Example: Pi-hole
Pi-hole's pattern requires:
- DNS port open (53/tcp OR 53/udp) AND
- HTTP response from
/admincontains "pi-hole"
Both conditions must be true for Pi-hole to be detected.
Example: Plex
Plex's pattern accepts either:
- HTTP response from port 32400
/web/index.htmlcontains "Plex" OR - HTTP response has
X-Plex-Protocolheader
Either condition is sufficient.
Confidence Levels
Each detected service has a confidence level indicating match strength.
| Level | Meaning |
|---|---|
| Certain | System services only (Scanopy Daemon, Docker Daemon) |
| High | Strong match — endpoint content or header matched |
| Medium | Moderate match — MAC vendor or unique port |
| Low | Weak match — common port, could be multiple services |
| N/A | Generic service — definitional match (port 53 = DNS) |
Generic Services
Some services are generic — they're defined by their port alone:
- Port 53 → DNS Server
- Port 5432 → PostgreSQL
- Port 22 → SSH
These show "N/A" confidence because there's no uncertainty. Port 53 is DNS by definition. If you're running a specific DNS server (Pi-hole, AdGuard), it will be detected separately with its own pattern.
Improving Detection
Use default ports — Detection patterns are written for standard ports. Check scanopy.net/services for which port each service expects.
Use Docker discovery for containers — Docker discovery inspects the Docker API directly, so it works for containers on internal networks without port exposure. It's more reliable than network scanning for containerized services.
Requesting New Service Detection
If a service isn't detected:
- Check existing definitions at scanopy.net/services
- Report a detection issue if Scanopy should have detected it but didn't: Service detection issue
- Request a new service if it's not in the list: Missing service request
When requesting, include:
- Service name and what it does
- Default port(s)
- Any unique HTTP endpoints or headers
- How you currently identify it