🔐 Vault Error: 'error checking seal status ... connection refused' From the CLI

Exact Error Message

$ vault status
Error checking seal status: Get "https://127.0.0.1:8200/v1/sys/seal-status":
dial tcp 127.0.0.1:8200: connect: connection refused

If the port is open but the scheme is wrong, you get a TLS error instead, which is a different problem:

$ vault status
Error checking seal status: Get "https://127.0.0.1:8200/v1/sys/seal-status":
http: server gave HTTP response to HTTPS client

What It Means

connection refused is a TCP-level rejection: the kernel on the target host answered the SYN with a RST because nothing is listening on that address and port. No HTTP request was ever made, no TLS handshake was attempted, and Vault’s own state is irrelevant — the CLI never reached it. The two variables that determine where the CLI dials are VAULT_ADDR and the server’s listener "tcp" stanza, and this error means they disagree, or the server is not running.

The default deserves special attention. When VAULT_ADDR is unset, the CLI dials https://127.0.0.1:8200. A dev server started with vault server -dev listens on 127.0.0.1:8200 over plain HTTP, and it prints the correct VAULT_ADDR=http://127.0.0.1:8200 on startup precisely because the default is wrong for it. If you skip that export you will usually see the TLS-mismatch variant rather than connection refused, since something is listening. A true connection refused means the process is down, bound to a different address or port, or blocked before it reaches the host.

Common Causes

• The Vault service is not running or crashed on startup due to a config error.
• VAULT_ADDR is unset and defaults to https://127.0.0.1:8200 while the server listens elsewhere.
• The listener "tcp" stanza binds a specific interface (127.0.0.1) and you are connecting from another host.
• A non-default address port is configured but the client still assumes 8200.
• A host firewall or security group drops or rejects traffic to the API port.
• You are inside a container or pod and 127.0.0.1 refers to that container, not the Vault host.

Diagnostic Commands

Check whether the service is running and whether it exited during startup:

systemctl status vault --no-pager
journalctl -u vault -n 100 --no-pager

Confirm what is actually listening, on which address, and on which port:

sudo ss -lntp | grep -E '8200|vault'

See exactly where the client intends to connect:

env | grep -E '^VAULT_(ADDR|CACERT|NAMESPACE|SKIP_VERIFY)='

Read the listener configuration on the server:

grep -A10 'listener "tcp"' /etc/vault.d/vault.hcl

Test raw TCP reachability, separating network problems from Vault problems:

nc -vz 127.0.0.1 8200
curl -sv http://127.0.0.1:8200/v1/sys/seal-status 2>&1 | head -20

Step-by-Step Resolution

1. Establish whether anything is listening. If ss shows no socket on 8200, the server is down and no client-side change will help:

sudo ss -lntp | grep 8200
# LISTEN 0 4096 127.0.0.1:8200 0.0.0.0:* users:(("vault",pid=1421,fd=9))

2. If the service is not running, start it and read the logs immediately. Vault exits on a malformed configuration, and the reason is always in the first few log lines:

sudo systemctl start vault
journalctl -u vault -n 50 --no-pager | grep -iE "error|failed|listener|storage"

3. Point VAULT_ADDR at the address and scheme the server actually serves. For a dev server that is plain HTTP on loopback:

export VAULT_ADDR='http://127.0.0.1:8200'
vault status

For a production listener with TLS enabled, use https and the hostname that matches the certificate’s SAN:

export VAULT_ADDR='https://vault.example.com:8200'
vault status

4. Reconcile the listener stanza with what clients expect. Binding to 127.0.0.1 makes Vault unreachable from anywhere but the host itself; bind to a routable address or 0.0.0.0 for a real cluster, and always set api_addr so HA redirects point somewhere clients can reach:

listener "tcp" {
  address       = "0.0.0.0:8200"
  tls_cert_file = "/opt/vault/tls/vault.crt"
  tls_key_file  = "/opt/vault/tls/vault.key"
}

api_addr     = "https://vault-node-1.internal:8200"
cluster_addr = "https://vault-node-1.internal:8201"

Only a dev or lab listener should carry tls_disable = true, and if you set it you must use http:// in VAULT_ADDR:

listener "tcp" {
  address     = "127.0.0.1:8200"
  tls_disable = true
}

5. Apply the config change and confirm the new bind address took effect. Vault re-reads listener configuration on restart, not on SIGHUP:

sudo systemctl restart vault
sudo ss -lntp | grep 8200
vault status

6. If the socket is listening locally but a remote client still gets connection refused or a timeout, work outward through the network path — host firewall first, then any cloud security group, then the load balancer:

sudo firewall-cmd --add-port=8200/tcp --permanent && sudo firewall-cmd --reload
# or, on ufw
sudo ufw allow 8200/tcp
# from the client
nc -vz vault-node-1.internal 8200

Once the connection succeeds, the next thing you see is likely Sealed: true, which is the normal post-restart state and is handled in Vault error: “Vault is sealed”. If instead the TCP connection opens and the handshake fails with a certificate complaint, you have a trust problem rather than a connectivity one — see Vault error: “certificate signed by unknown authority”. Resist the temptation to reach for VAULT_SKIP_VERIFY=true; it disables server certificate validation entirely and exposes every token you send to interception. It is acceptable only as a momentary, clearly-labelled diagnostic to confirm that TLS trust is the variable, never as a fix or a setting you leave in a config file, a Dockerfile, or CI.

Prevention

• Set VAULT_ADDR in a shell profile, systemd drop-in, or container env so it is never left at the wrong default.
• Always set api_addr and cluster_addr explicitly so HA redirects use reachable names.
• Keep tls_disable = true out of every non-dev configuration and enforce that in config review.
• Add a startup smoke test that curls /v1/sys/health from a client host, not just from the Vault node.
• Validate configuration before restarting a node so a typo does not take a cluster member down.
• Monitor the listening socket and the health endpoint separately — one catches a dead process, the other a sealed one.

Related Errors

• context deadline exceeded / i/o timeout — packets are dropped rather than rejected, usually a firewall or security group.
• http: server gave HTTP response to HTTPS client — the port is open but VAULT_ADDR uses the wrong scheme.
• x509: certificate signed by unknown authority — TLS is working but the client does not trust the CA.
• Vault is sealed — the connection succeeded and Vault is up but has not been unsealed yet.

Frequently Asked Questions

Why does vault status try HTTPS when my dev server is HTTP? The CLI’s built-in default is https://127.0.0.1:8200. A dev server serves plain HTTP, which is why it prints the VAULT_ADDR=http://127.0.0.1:8200 export line at startup. Run that export.

The service says active but nothing is listening on 8200. Check the address in the listener "tcp" stanza — a non-default port or an unexpected interface is the usual answer. ss -lntp shows the truth regardless of what the config claims.

Can I run Vault on a different port? Yes, set address = "0.0.0.0:8300" in the listener and update api_addr and every client’s VAULT_ADDR to match. Vault does not discover the port for you.

Should I just set VAULT_SKIP_VERIFY to make this go away? No. That flag only affects TLS verification, will not fix a refused connection at all, and silently removes the protection that keeps your tokens from being intercepted. Use VAULT_CACERT to trust the right CA instead. More connectivity and TLS fixes are collected in the Vault guides.