Synapse: 33,077 title matches, 14,449 fingerprint matches, and 14,111 answers on the listener its reverse-proxy guide assumes

Synapse is the reference homeserver implementation for Matrix. It serves a federated chat protocol, which means every deployment expects to talk to servers it has never met, and that expectation shapes how it is deployed and how much of it is meant to be reachable.

The measurements

Three queries on 2026-10-26, one result page each, totals only:

• title="Synapse" returned 33,077 matching assets.
• app="Synapse" returned 14,449 matching assets.
• title="Synapse" && port="8008" returned 14,111 matching assets.

The third number is 97 percent of the second, and both sit well under the loose title count. This shape fits a product with a strong application signature whose listeners cluster on one port.

Reading the gap honestly

The difference between 33,077 and 14,449 is not a defect. Synapse is a word used by other software: a package index, a plugin, a security product, and several unrelated dashboards carry it in a page title. A loose title match collects all of them.

The fingerprint count is the better population estimate, and the number that resembles it, 14,111, is the subset answering on 8008. That port is the one Synapse's own reverse-proxy documentation uses when it shows how to forward traffic from an HTTPS listener to the homeserver. A deployment that follows the documentation puts the homeserver behind a proxy and leaves it on that port.

So the measured shape is coherent: a five-figure population of homeservers, most of them on the port their own guide names, with a title-level population inflated by a common English word.

What a homeserver holds

Matrix is a messaging platform, and a homeserver is the store of record for its users. It holds room history, attachments, device keys, and the access tokens of every client session. Federation adds a second dimension: the server exposes endpoints to other homeservers, and the set of endpoints it exposes is part of the protocol.

That produces a deployment pattern worth understanding before the review. An operator publishes a federation endpoint because the protocol requires it, and the client API often shares the same reverse proxy. The two have different trust models. The federation API expects requests from strangers; the client API expects requests from authenticated users.

Whether those two are separated by the proxy is a configuration decision, and it is the most consequential one in a Synapse deployment.

The review, in the order that matters

Start with the proxy, not the homeserver. Which listener does the public interface forward to, and does that path include the client API, the admin API, and the federation endpoints in the same virtual host? A single virtual host is convenient and it means every endpoint shares one set of protections.

Then check the administration surface. Synapse has an admin API with a registration shared secret and, in recent versions, a matrix-authentication-service integration. The configuration documentation lists these explicitly, and it is worth reading the section for the version actually deployed rather than the version in a blog post.

Then check registration. An open registration flow on a public homeserver is an account creation interface for anyone. That may be intended, and it should be a recorded decision with a rate limit.

Finally, check the media repository and the database. The homeserver's own documentation distinguishes deployment modes, and a media repository that is reachable without authentication is a different finding from one that requires a token.

Detection

Two useful signals. The first is a federation request from a server name that the deployment has never federated with, in a volume that suggests scanning rather than conversation. That is visible in the homeserver's own logs and in the proxy logs.

The second is a client API session created from an address that has never authenticated before, particularly against the registration endpoint. Both signals need the proxy and the application logs to be joined on request identifiers, which is the part that usually is not done.

Method and limits

Queries ran on 2026-10-26 with sub_type=all and one result page requested; only totals were used. Port 8008 is treated as a deployment convention from the project's own documentation, not as a required port. Federation on 8448 and client traffic on 443 are both common and both fall outside the port-scoped count by definition.

The report does not claim that any matched homeserver is open for registration, that any federation endpoint is misconfigured, or that the population is reachable beyond the scanner. It reports three counts and what their relationship supports.

Why the measurement is worth keeping

Federated software is a class where exposure is intrinsic: the protocol's purpose is to accept requests from unknown servers. That makes the inventory question sharper than for a normal web application, because "should this be public" is already answered yes. The remaining question is which parts should be public, and a homeserver's own documentation is unusually clear about the answer.

A count of homeservers that answer on the listener their guide assumes is a decent starting denominator for that conversation.

References

• ZoomEye observation, app="Synapse", recorded 2026-10-26: https://www.zoomeye.ai/searchResult?q=YXBwPSJTeW5hcHNlIg%3D%3D
• ZoomEye observation, title="Synapse" && port="8008": https://www.zoomeye.ai/searchResult?q=dGl0bGU9IlN5bmFwc2UiICYmIHBvcnQ9IjgwMDgi
• Synapse reverse proxy documentation, which uses port 8008 in its examples: https://element-hq.github.io/synapse/latest/reverse_proxy.html
• Synapse configuration documentation: https://element-hq.github.io/synapse/latest/usage/configuration/config_documentation.html