Troubleshooting: my airdress does not answer

Clients time out, get refused, or see a DNS or certificate error when they open your airdress. Work along the path a request takes: the hub’s view first, then DNS, then the relay or IPv6, then the certificate. Network architecture shows that path.

Tip

Replace myname with your airdress’s name throughout. airdress current prints the airdress the CLI is acting on.

Quick checks

# 1. Can the hub reach it, and how?
airdress airdress probe

# 2. Does the name resolve at the authoritative DNS?
dig +short A    myname.a.airdr.es @185.43.32.1
dig +short AAAA myname.a.airdr.es @185.43.32.1

# 3. What does a client see?
curl -v https://myname.a.airdr.es/

Then go to the section that matches what you saw.

The probe says unreachable

airdress airdress probe asks the hub to reach your airdress. It prints the addresses it tried and the transport that worked: direct (IPv6), direct (IPv4), relay (IPv4), or unreachable with an error.

• unreachable with a timeout: your airdress is not answering at all. Check the status page for an incident, then contact support with the probe’s output.
• The CLI itself exits 4: your sign-in lapsed. Run airdress auth login and probe again.
• The CLI exits 5: the CLI could not reach the hub. Check your own network first; exit codes explains the rest.

Add --output json to the probe to get the same answer as structured data, which is the best thing to paste into a support request.

DNS does not resolve

At the authoritative DNS (185.43.32.1):

• the A record should be 23.163.148.11, the relay;
• the AAAA record should be your airdress’s own IPv6 address.

What dig shows	What it means	What to do
Both records present	DNS is fine	Go on to the relay and IPv6 checks
NXDOMAIN	The name does not exist	Check the spelling, then that the airdress is listed by airdress airdress list
Nothing, but the airdress was claimed minutes ago	The record is still being written	Wait a few minutes and ask again
Correct at 185.43.32.1, wrong at your own resolver	A cached old answer	Wait for the TTL, or ask a public resolver: dig @1.1.1.1 …

The relay drops the connection (IPv4)

A client on IPv4 reaches your airdress through the relay at 23.163.148.11, which routes by the name in the TLS handshake (SNI) or the HTTP Host header.

• Connect by name, not by address. curl https://23.163.148.11/ will always fail: without a name, the relay cannot tell which airdress you mean, and drops the connection without answering.
• Names outside your airdress are dropped too. A domain of your own must point at your airdress as described in Your own domain.
• Force IPv4 to test this path: curl -4 -v https://myname.a.airdr.es/.

IPv6 works and IPv4 does not, or the other way round

The two paths are independent: IPv6 clients connect to your airdress directly, IPv4 clients through the relay. Test each:

curl -4 -sS -o /dev/null -w '%{http_code}\n' https://myname.a.airdr.es/
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://myname.a.airdr.es/

If only IPv4 fails, include both results when you contact support. If only IPv6 fails, check that your own network really has IPv6 (curl -6 https://airdress.co fails without it).

Certificate errors

Your airdress holds its own certificate; the relay never does.

openssl s_client -connect myname.a.airdr.es:443 -servername myname.a.airdr.es </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

• The name does not match, or the certificate has expired: ask your airdress to renew it now:

  airdress tls renew
  airdress tls renew --rotate   # revoke the old one first, if renewal hands back the same certificate

• A brand-new airdress: its first certificate is issued within minutes of the name resolving. Wait, then check again.

Still stuck?

Collect what the CLI sees and send it to support@airdress.co:

airdress version
airdress current --output json
airdress airdress probe --output json

Airdress statusActive incidents and scheduled maintenance.