ClickHouse network ports and firewall rules

Which ClickHouse ports to expose, and to whom

The job is to map each ClickHouse listener to the sources allowed to reach it, then close every other path. A team that has installed ClickHouse needs this decision made before any client or application connects, and again before a cluster moves onto a shared network. A ClickHouse server does not expose one port. It runs separate listeners for client queries, the native and HTTP interfaces, ClickHouse Keeper coordination, inter-server replication traffic and monitoring endpoints. The server can also open MySQL and PostgreSQL emulation listeners, which are easy to forget because they are disabled in some configurations and enabled in others. Confirm the default ports and the enable flags for your installed version in the official documentation before you write any rule, because defaults and settings differ between releases.

Most of the work is configuration review followed by firewall rules. Start by listing every listener that the server and Keeper nodes actually open, using the server configuration files and the listening sockets on each host. Then assign each one a single audience: application clients, other ClickHouse servers, Keeper peers, or the monitoring system. The listen_host settings control which network interfaces each service binds to, so a listener bound to all interfaces can be reachable from networks you did not intend, even when a firewall exists. Bind internal listeners to the interface they need, disable emulation ports your applications do not use, and write allow rules per audience with a default deny policy on each host. Keep Keeper traffic and replication traffic on paths that only other cluster members can reach.

Verify the result from outside the intended sources, not only from the server itself. Run a scan or connection test from an application subnet, a monitoring host and an unrelated network, and confirm that only the expected listeners answer. Record the final port matrix in your change records, because every new feature, such as a new integration or a new monitoring agent, adds a listener or a source. Ask your security team to confirm whether the matrix matches the network segmentation and the access rules you have already agreed for the environment.

Listeners, their purpose and who should reach them

This table maps each ClickHouse and Keeper listener family to its typical clients and the audience that should reach it. Use it to decide which listeners stay open, which are limited to cluster hosts or monitoring, and which should be disabled. Confirm each listener's settings in the configuration reference for your installed version before writing firewall rules.

Listener	Typical clients	Who should reach it	What to confirm in configuration	Recommended action
Native client protocol (plain)	clickhouse-client, drivers and applications using the native protocol	Approved application and analyst subnets only	Whether the plain native listener is enabled, and whether a TLS listener replaces it for remote clients	Restrict to client networks, or disable once TLS is in place
Native client protocol (TLS)	Drivers and applications connecting over encrypted native protocol	Approved application and analyst subnets	Certificate paths, verification mode and the TLS listener being enabled	Expose to client networks
HTTP interface (plain)	Browsers, HTTP clients, BI tools and ingestion pipelines	Approved client subnets and load balancers only	Whether plaintext HTTP is enabled and which hosts it listens on	Restrict to client networks, or disable once HTTPS is in place
HTTP interface (TLS)	HTTPS API clients, BI tools, ingestion services and load balancers	Approved client subnets and load balancers	Certificate chain, verification settings and the HTTPS listener being enabled	Expose to client networks
Inter-server replication (plain)	Other replicas of the same shard for fetching data parts	Cluster hosts only	Whether plaintext replication port is enabled and the interserver address each host advertises	Restrict to cluster hosts, or disable if TLS replication is used
Inter-server replication (TLS)	Replicas fetching parts over encrypted interserver traffic	Cluster hosts only	Certificate settings for interserver communication and matching configuration on every replica	Restrict to cluster hosts
Keeper client and Raft listeners	ClickHouse servers connecting to Keeper, and Keeper nodes forming quorum	ClickHouse servers and other Keeper nodes only; clients never	Client and Raft ports, TLS settings, and that only dedicated Keeper hosts run the listener	Restrict to ClickHouse server and Keeper hosts. Applies only where Keeper runs
Keeper or server metrics endpoints	Prometheus scrapers and monitoring collectors	Monitoring hosts only	Whether the metrics endpoint is enabled, its bind address and whether authentication applies	Restrict to monitoring, or disable if not scraped
MySQL and PostgreSQL emulation ports	Legacy MySQL or PostgreSQL client tools, if any	Nobody by default	Whether these emulation listeners are enabled on each node and whether any client depends on them	Disable unless a documented client need exists

Rules for clients, cluster peers, Keeper and monitoring

Application services and analyst tools connect to ClickHouse over the client-facing listeners. These are the only listeners that should be reachable from user-facing networks, and they should be exposed only to the specific subnets, load balancers or bastion hosts that carry those connections. Start by listing every application, BI tool and analyst workstation group that connects, then confirm which protocol each one uses.

Client listeners: Enable only the protocols your clients use. Each protocol has its own listener and its own enable setting, so confirm each one in the configuration reference for your version.
Bind address: Use listen_host to limit where the server accepts connections. Binding to all interfaces is the default in many setups, so check the effective value on every node.
Source addresses: Allow named application subnets or load balancer addresses in the firewall, not the entire corporate network. Analysts who need direct access should come through a jump host.
Plaintext next to TLS: If a TLS listener is enabled, make sure the matching plaintext listener is disabled or firewalled for clients that must use encryption. Leaving both open is a common gap.
Verification: From an allowed address, confirm the expected client connects. From a disallowed address, confirm the connection is refused on every client listener, including the plaintext one.

After each change, test from every node and from outside the allowed range, because a rule that works from one host can still leave another interface open.

ClickHouse Keeper coordinates replicated tables, and its nodes talk to each other on a consensus channel and to ClickHouse servers on a client channel. Keeper hosts should be dedicated and placed in a segment that only ClickHouse servers and Keeper peers can reach. Keeper also has administrative commands that should not be exposed beyond the operations team, so treat its listeners as a separate policy from the data cluster.

Client channel: Allow connections only from the ClickHouse server addresses that use this Keeper ensemble. Check the Keeper client listener in the reference for your version.
Peer channel: Allow only the other Keeper nodes on the consensus port range. Confirm the Keeper server configuration lists every peer correctly.
Bind settings: Set listen_host for Keeper to the private interface so it does not accept connections on management or client networks.
Administrative commands: Restrict the diagnostic commands to a small set of operator addresses, and confirm which commands your version exposes before opening anything.
Verification: Confirm the ensemble reports a leader and that replicated tables stay healthy. From a non-ClickHouse host, confirm the client channel refuses connections.

If Keeper shares hosts with other services, the firewall rules for Keeper become harder to audit, which is one reason to keep it on dedicated hosts.

How to lock down ports in a fixed sequence

This sequence moves a ClickHouse and Keeper cluster from whatever listeners happen to be enabled to a documented set of open ports, with each source zone verified against that set. The result is a configuration you can explain, reproduce on every node and check after each change.

Inventory every enabled listener
Start by recording what each node actually exposes. Read the server and Keeper configuration, including every file in the config.d and users.d directories, and note each enabled listener such as the native, HTTP, interserver, Keeper client and Raft ports, plus any MySQL or PostgreSQL emulation ports. Then run a socket listing on each host, using a tool such as ss -ltnp, and compare it with the configuration. Mismatches usually come from drop-in files that override the main config, so resolve them before moving on. The step is done when every host has a written list of listeners and the reason each one exists.
Assign an allowed source to each listener
For each listener, decide which zones may connect: application clients, other ClickHouse replicas and shards, Keeper nodes, monitoring scrapers, and administrators. Keep the interserver and Keeper Raft ports limited to the peer hosts rather than the whole subnet where your network allows it. Record the decision in a table with columns for port, purpose, allowed sources and owner. The output is an approved matrix that the security team and platform team both sign off on before any firewall change is made.
Bind only the interfaces you intend
Set listen_host in the server configuration to the addresses that should accept traffic, rather than leaving the default that may bind broadly on a multi-homed host. Apply per-listener settings so that unused protocols are not started, and disable MySQL and PostgreSQL emulation listeners that no client uses. Confirm in the documentation for your installed version which of these settings require a restart and which take effect on reload, and plan the restarts across replicas and Keeper nodes so quorum and read availability are preserved. The check is that the socket listing on each host now matches the approved matrix, with no unexpected addresses or ports bound.
Write firewall rules per zone
Translate the matrix into host firewall rules, such as nftables or firewalld, or into security group rules in a cloud account. Where your network supports it, add network ACLs at the subnet boundary as a second layer. Default to deny for inbound traffic and add explicit allow rules for each source zone and port pair. Keep the rule set in version control and apply it through the same change process as the configuration. The check is that the rendered rule set on each host matches the matrix row for row, and that any rule not in the matrix is removed.
Verify from each allowed zone
From a host in each approved source zone, test every port that zone should reach, and confirm the connection succeeds. Use the native and HTTP clients that your applications use, and a Keeper client test for the coordination port. This step catches rules that are too narrow, such as a missing peer address for interserver replication, which can show up only as stalled replication rather than a clear error. The check is a written test result per zone and port, with any failures traced back to the matrix or the rule set.
Verify refusal from blocked zones
From a host in a zone that should not reach a port, confirm the connection is refused or dropped. Test the emulation ports and the Keeper ports in particular, since they are easy to leave open by accident. Then run a port scan from outside the trusted networks against each node, using an approved scanning tool and scope, and compare the results with the matrix. Any port that answers but is not in the matrix is a finding to fix and retest. The check is a clean scan result that matches the approved list.
Confirm monitoring and replication still work
After the rules are in place, confirm that the monitoring system still scrapes each node and that replicated tables continue to sync between replicas. Check that Keeper reports healthy membership and that no replica is stuck in a read-only or lagging state. Keep the matrix and the rule set under change control, and repeat the listener comparison and scan whenever a configuration file or firewall rule changes. The output is a monitoring confirmation and a replication health check recorded alongside the approved matrix.

Closing MySQL and PostgreSQL emulation ports without breaking tools

ClickHouse can accept connections over the MySQL and PostgreSQL wire protocols in addition to its native and HTTP interfaces, so a BI tool or script that speaks one of those protocols can query the server without knowing ClickHouse at all. Each of these is a separate listener with its own authentication path, which means your firewall scope and your access model must cover it just as they cover the native and HTTP ports. Closing a port you have not inventoried is the most common way this change breaks a reporting pipeline, so the first task is to find out who uses it. Do not close an emulation listener until you have confirmed what connects to it.

Start by reviewing the server's query log for connections grouped by protocol and client address over a period long enough to include month-end jobs, weekly extracts and any ad hoc analyst activity. Then ask the owner of every tool, script and ETL job that appears, and ask them directly whether any of their connections use the MySQL or PostgreSQL protocol, including drivers and connection strings they inherited from a template. Agree a change window with those owners and write down the rollback step, which is normally restoring the previous listener configuration and restarting or reloading the server, after you confirm the exact reload behavior for your version in the official documentation. Remove the listener from configuration on every node, not only the one you tested on, and keep the native or HTTP path open for the clients that need it.

Closing a listener does not make the remaining ones safe by default. Any protocol that stays open is still governed by the users, roles, grants and authentication methods defined on the server, so an open HTTP or native port with a permissive account is still a path in. Review the users those clients authenticate as and confirm that each one has only the grants its job needs. For that review, see the guidance on role-based access control and on securing the default user elsewhere in this group, and check that no shared account is used across tools that you plan to separate.

Network exposure risks to review before go-live

Most ClickHouse exposure incidents trace back to a listener that was reachable from more networks than anyone intended. The cards below cover the common ways that happens, from default bind addresses to Kubernetes services, and the checks to run before production traffic arrives. Because the default user starts with full permissions, every listener reachable from a wide network raises the stakes.

Listeners bound to all interfaces

ClickHouse listens on addresses set by listen_host in the server configuration. Leaving that setting broad, or copying a sample config without reading it, can expose HTTP, native and inter-server listeners on every network interface a host has, including management and backup networks. Set listen_host to the specific addresses each client group needs, and confirm the bind with a socket listing on each node. Check that a scan from outside the intended subnet finds nothing open.

Plaintext listeners beside TLS

Enabling TLS does not disable the plaintext listener. The HTTP and native ports often stay open next to their secure counterparts, so credentials and queries can still travel unencrypted. Decide which protocols are permitted, close the plaintext ports for every client path that supports TLS, and verify that connections on those ports are refused. Review this after every certificate or configuration change, since a restored default can reopen them.

Inter-server and Keeper ports reachable from app subnets

Replication traffic between ClickHouse servers and coordination traffic to ClickHouse Keeper should only flow between the cluster members. When application subnets can reach these ports, any client that can open a socket may attempt to join or disturb replication. Restrict the inter-server port and Keeper client and Raft ports to the server and Keeper hosts only. Confirm that application hosts cannot connect by testing from a representative application node.

Emulation ports bypassing the client path

ClickHouse can expose MySQL and PostgreSQL wire-protocol emulation ports. These give tools a familiar connection path, but they also create a second entry point that may sit outside the controls applied to the HTTP and native interfaces. Disable any emulation port your clients do not use, remove it from firewall allow lists, and confirm that the enabled protocols match an approved client inventory. Recheck after upgrades, because defaults and supported protocols can change.

Monitoring endpoints exposed to wide networks

Metrics endpoints and the built-in dashboard reveal query text, table names, user activity and cluster topology. Scrapers in a monitoring network often reach the same listener that serves application traffic, which widens the audience for that data. Restrict metrics access to the monitoring subnet, or bind a dedicated listener for it, and review who can reach the dashboard. Check that scrape targets resolve only from the monitoring network and that the dashboard is not published to general users.

Load balancers and Kubernetes services publishing listeners

A load balancer, NodePort or ingress rule can publish a ClickHouse listener that the team meant to keep internal. Cloud security groups and Kubernetes service types often default to broader exposure than the database requires. Use internal load balancers or ClusterIP services for internal clients, and list every published port in your infrastructure code. Compare the published ports with the ports ClickHouse actually listens on, and confirm that no external address resolves to a database listener.

Questions teams ask before changing ClickHouse network rules

How much effort does a ClickHouse firewall review take?

The effort depends mostly on how many listeners and hosts are involved and how well the network is already segmented. A single cluster with clear zones and few listeners is a short review. A larger estate with many hosts, several listening interfaces per node, and unclear ownership of firewall rules takes longer, because every listener and every client path has to be traced before a rule changes. The number of applications still using MySQL or PostgreSQL emulation ports also adds work, since each one needs its own connection check. Ask for the review to be scoped by host count, listener count, zones and emulation-port clients, and for the scope to be written down before work starts.

Can our own team close ClickHouse ports without outside help?

Yes, many teams do this in-house, provided they have the right access and a safe place to test. You need access to the ClickHouse and Keeper configuration on every node, including listen_host settings and any users.d files, a named owner for the firewall rules in each zone, and a test environment with representative clients. Without a test environment, the first real check is usually a production outage. A partner is useful when the estate is large, the ownership is split across teams, or the rules must be evidenced for an assessment. Confirm which of these you have before deciding.

What do we need to provide before a ClickHouse port review starts?

The most important input is an inventory of every application and tool that connects to ClickHouse or Keeper, with the connection type for each. Include native protocol clients, HTTP and HTTPS clients, JDBC or ODBC drivers, MySQL or PostgreSQL emulation users, replication traffic between servers, Keeper client and peer traffic, and monitoring scrapers. Add the source address ranges or zones each one uses, and the owner to contact when a connection breaks. Without this list, the reviewer cannot tell which open ports are needed and which are only left over from defaults.

How are port changes rolled out safely across replicas and Keeper nodes?

Changes should go in one node or one zone at a time, with a check after each step, so that a bad rule can be reversed without taking the cluster down. For replicas, the usual approach is to confirm that the other replicas of each shard are healthy before touching one node, then apply the rule, verify the replication queue drains, and move on. Keeper nodes need more care, because the ensemble depends on a quorum. The replication guide recommends at least three Keeper nodes in production, so change one Keeper node at a time and confirm it rejoins before the next. Keep the previous rule set ready to restore.

Does closing a port affect replication or monitoring?

It can, if the closed port is one that servers or scrapers use. Replication between replicas and coordination traffic with Keeper use their own ports, so a rule that blocks them stops replication, and a recovered replica needs a path back to a healthy peer to sync missing data. Monitoring can break in the same way when a Prometheus scraper or health check loses access to its endpoint. Closing an emulation port affects only the clients that use it. Map every port to its traffic before closing it, and test replication and monitoring after each change, not only the client connections.

What should a written quote for ClickHouse network work include?

A useful quote lists the hosts in scope by name or role, the listeners on each host (native, HTTP and HTTPS, interserver, Keeper, metrics and emulation ports), and the network zones or firewall points that will change. It should state what verification is included, such as connection tests per client type, replication checks, Keeper quorum checks and monitoring checks. It should also describe the rollback method for each step and who signs off each change. Ask whether the fee covers the client inventory, the test environment work and the written change record, and what is excluded. Quotes are issued from the written scope, so a vague scope produces a vague quote.

Who owns the firewall rules after the review is finished?

Ownership should be settled before the work starts, because rules drift when no one owns them. Name the team that maintains each firewall zone, the team that maintains ClickHouse configuration, and the person who approves changes to client-facing ports. Record the expected open ports per role, so later changes can be compared against the baseline. Confirm in writing whether any ongoing review or retainer is included, since port rules change when new applications, Keeper nodes or monitoring tools are added.

What to confirm in your environment and version

Port and listener behavior depends on the exact release you install, how your network is built, and which features your topology uses. The cards below list the checks to run against the configuration reference and release notes for your version before any firewall change is approved.

Default listeners for your version

Confirm the default ports and listener settings in the configuration reference for the exact release you run, including the HTTP, native, secure variants and the MySQL and PostgreSQL emulation ports. Defaults have changed across releases, so do not copy port numbers from an older runbook or blog post. Record what is actually listening on each node with a socket listing after the install, and compare it with the firewall policy you intend to apply.

Release line in the supported list

Check whether your release line appears in the supported versions list of the security policy before you finalize exposure decisions. Versions outside that list receive no security updates, so a port you open on an unsupported build carries unpatched risk. Confirm the current list on the day you deploy, because the policy changes as new lines are released and older ones retire.

Load balancer and container binding

Determine how Kubernetes services, container port mappings, and any managed or software load balancer change the address each listener binds to and the address clients appear from. A listener bound to localhost inside a container will not accept traffic from a service, while a wildcard bind may expose ports you meant to keep internal. Check the source addresses your firewall sees after the load balancer, because allow lists built on client IPs fail silently when proxies rewrite them.

Keeper and replication listeners in use

Decide whether your topology uses ClickHouse Keeper, and if so, which Keeper client, Raft and secure ports are active on each Keeper host and each server. Replicated tables need traffic between replicas for data fetches, and a single-node or non-replicated deployment does not. Map every inter-node flow to a rule, and remove rules for Keeper ports on hosts that run no Keeper role. The replication guide describes the recommended Keeper layout for production.

Monitoring and scrape ports

List every monitoring tool that reads ClickHouse, including Prometheus scrapers, agents that query system tables over HTTP or the native protocol, and uptime checks. Confirm which endpoint each tool uses, whether it needs TLS, and which source hosts it runs from. Scope these rules to the monitoring subnet rather than to all clients, so a metrics endpoint does not become a query path for application traffic.

Emulation listeners and application dependencies

Ask every application team whether they connect through the MySQL or PostgreSQL emulation ports, since BI tools and legacy drivers sometimes do. If a dependency exists, decide whether to keep that port on a restricted subnet, move the client to the native or HTTP interface, or disable the listener. Confirm the setting names and defaults in the configuration reference for your version, and test each client after the firewall change, because a blocked port usually shows up as a connection error at the application level.

How DeployOpen scopes and delivers ClickHouse network hardening

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For ClickHouse network ports and firewall rules, we start from a written scope that maps every listening port, the clients and servers that need it, and the monitoring paths that reach it.

How we scope

Inventory every ClickHouse and Keeper listener, its purpose and the hosts that should reach it.
Confirm which plaintext protocols, emulation ports and admin interfaces must close before go-live.
Agree the written scope, deliverables and timeline with you before any work starts.

How we build

Set listen_host values and bind addresses per node so only intended interfaces accept connections.
Write firewall rules for client, inter-server, Keeper and monitoring flows, then test each one from both sides.
Validate the configuration on a pre-production cluster with representative traffic before changing production.

How we hand over

Deliver a port matrix, rule set and configuration files that your team can review and version.
Document the test results, including blocked ports and the commands used to confirm them.
Walk your operations and security staff through change steps for adding new clients or nodes.

How we support

Offer ongoing support and periodic port reviews as a retainer after handover.
Re-check exposure after ClickHouse upgrades, new nodes or changes to monitoring systems.
Confirm firewall and listener behavior against the current release notes before each upgrade.