perf-metrics port 7000 conflict on Windows: No way to configure alternative port (svchost.exe often claims 7000)

[TheCEOCoreGroupMining]

Describe the bug
When running Kaspad v1.0.1 (Windows 10, official binary), enabling the --perf-metrics flag causes Kaspad to always bind the Prometheus metrics server to 0.0.0.0:7000. On Windows, this port is often already occupied by system processes (commonly svchost.exe), resulting in the inability to access metrics and (sometimes) node startup failure.
There is currently no CLI flag or config file option to specify an alternative metrics port.

To Reproduce
Steps to reproduce the behavior:

1. On Windows, ensure any process (like svchost.exe) is listening on port 7000
2. Launch Kaspad with --perf-metrics
3. Observe that Kaspad tries to bind 0.0.0.0:7000, but the port is occupied
4. Metrics endpoint is unavailable and/or node startup fails

Expected behavior
Kaspad should provide a way to specify a custom port for the Prometheus metrics endpoint, either by CLI argument (such as --metrics-addr) or config file.

At a minimum, the software should warn the user or fail gracefully, rather than silently being inaccessible.

Screenshots
Not applicable (but happy to provide if needed).

Desktop (please complete the following information):
-OS: Windows 10 (x64, build 26100.4652)
-Kaspad version: v1.0.1 (latest)
-Install type: official release binary

Additional context
Tried launching with possible options like --metrics-addr and via TOML config file; Kaspad either errors with “unexpected argument” or ignores config key.

Checked open/closed issues and changelog; there is no workaround described for metrics port conflicts.

Netstat confirms port 7000 is held by Windows services (svchost.exe), which is default behavior on some Windows installations.

Metrics endpoint is not accessible, breaking Prometheus monitoring.

Request
Please implement a CLI flag and/or config file option to set the Prometheus metrics port, e.g. --metrics-addr=0.0.0.0:7010 or equivalent.
Alternatively, if such a setting already exists, please clarify its usage in documentation.

Thank you!

[TheCEOCoreGroupMining]

Additional Context and Version Comparison

I’d like to clarify that this issue with the metrics port being unavailable due to a conflict with svchost.exe on Windows did not occur in version 1.0.0. My configuration, scripts, and Windows environment have remained unchanged between upgrading from v1.0.0 to v1.0.1.

v1.0.0 behavior:

Running kaspad.exe --perf-metrics started the node normally.

Metrics endpoint was available on port 7000 without any port conflict or errors.

No svchost.exe conflict observed on port 7000.

v1.0.1 behavior:

Running kaspad.exe --perf-metrics causes the node to fail if port 7000 is already bound by svchost.exe.

Changing the port via CLI arguments like --metrics-addr results in an “unexpected argument” error, suggesting it is not currently supported or documented.

There is no documentation or config option to change the metrics port in the latest release, as far as I can tell.

Summary:
This appears to be a regression or change introduced in v1.0.1 related to port binding, CLI parsing, or Windows compatibility for the metrics endpoint. If you need any logs, further testing, or environment details, I’m happy to provide them.

Thank you for your attention to this!

[TheCEOCoreGroupMining]

TheCEOCoreGroupMining
commented just now (Update)

Adding an update here to share the only workaround we’ve found that reliably gets Prometheus‑style metrics onto a website until this port conflict is addressed.

Since v1.0.1 offers no way to change the --perf-metrics port from 7000, and on Windows that port is often occupied by svchost.exe, we’ve been forced to bypass direct node metrics entirely. Instead, we’re pulling the needed values from a public Kaspa explorer (in our case, explorer.kaspa.org) and feeding them into a small custom API that our site queries.

From an engineering perspective, it’s not ideal — it adds an external dependency and means our “live” network data is no longer coming directly from our own node. But for now, it’s the only way we’ve found to get a stable feed of metrics like DAA score and hashrate into our public UI without breaking on Windows systems where port 7000 is unavailable.

We’re in the middle of developing a new mining portal for the Pacific Northwest community, and one of our goals is to give miners real‑time network data straight from the source. This limitation means we have to route around our own node, which feels like a step backward.

Until there’s a way to specify a custom metrics port (CLI or config), this is the best workaround we’ve found. We’d love to see this addressed so we can go back to pulling data directly from our own node without relying on third‑party explorers.

Until there’s a way to specify a custom metrics port (CLI or config), this is the best workaround we’ve found. We’d love to see this addressed so we can go back to pulling data directly from our own node, instead of having to query public Kaspa explorers (like explorer.kaspa.org) for metrics.
Until then... Thank you