The app connects to localhost and reaches its own container. Use the database container's service name, or host.docker.internal for a database on the host (which must listen beyond 127.0.0.1).

Read the fix: Docker: "connection refused" to localhost from a container — how to reach the host

Not this?Start over

Likely cause

PostgreSQL isn't running, or doesn't listen where you connect

The server is stopped (or failed to start), listens only on localhost, or the client knocks on the wrong host or port.

Check it

sudo systemctl status postgresql --no-pager
sudo ss -tlnp | grep 5432

Read the fix: PostgreSQL "Connection refused … Is the server running?": find out why nothing answers on 5432

Not this?Start over

Likely cause

The password, or the way it's checked, doesn't match

A wrong password, a user that doesn't exist, or an MD5/SCRAM mismatch. The client sees the same message for all of them; the server log says which.

Check it

sudo tail -n 20 /var/log/postgresql/postgresql-*-main.log

Read the fix: PostgreSQL "FATAL: password authentication failed for user": find the real reason

Not this?Start over

Likely cause

Local connections check your system user

With peer authentication, connecting over the local socket as database user "app" only works for the Linux user "app". Run psql as that user, or connect over TCP with -h localhost.

Check it

sudo -u postgres psql

Read the fix: PostgreSQL "Peer authentication failed for user": connect the right way, or change pg_hba.conf

Not this?Start over

Likely cause

pg_hba.conf has no rule for this connection

The message names the host, user, database and whether SSL was used: pg_hba.conf needs a line that matches all of them.

Check it

sudo -u postgres psql -c "SHOW hba_file"

Read the fix: PostgreSQL "no pg_hba.conf entry for host": allow this connection, the safe way

Not this?Start over

Likely cause

All connection slots are taken

Every one of max_connections is in use, usually by connection pools that are too big, or idle sessions left open.

Read the fix: PostgreSQL "FATAL: sorry, too many clients already": find who holds the connections

Not this?Start over

Likely cause

The server is down, or doesn't listen where you connect

(111) is refused: MySQL isn't running, or bind-address keeps it on 127.0.0.1. (110) is a timeout: a firewall in between.

Check it

sudo systemctl status mysql --no-pager
sudo ss -tlnp | grep 3306

Read the fix: MySQL "ERROR 2003: Can't connect to MySQL server": read the number in brackets

Not this?Start over

Likely cause

The client can't find the server's socket

For localhost, the client uses a Unix socket file, not TCP: the server is stopped, or the socket is somewhere else. 127.0.0.1 uses TCP instead.

Check it

sudo systemctl status mysql --no-pager

Read the fix: MySQL "Can't connect to local MySQL server through socket": find out why (ERROR 2002)

Not this?Start over

Likely cause

The user, password or host don't match an account

"using password: NO" means no password was sent. Otherwise: a wrong password, the right user from the wrong host, or root on Ubuntu, which logs in with sudo instead of a password.

Check it

sudo mysql -e "SELECT user, host, plugin FROM mysql.user"

Read the fix: MySQL ERROR 1045 (28000): Access denied for user — find which part is wrong

Not this?Start over

Likely cause

No account for the host you connect from

MySQL accounts are user@host. The server knows you, but not from that address: create the account for the right host.

Check it

sudo mysql -e "SELECT user, host FROM mysql.user"

Read the fix: MySQL "ERROR 1130: Host is not allowed to connect": an account is a user and a host

Not this?Start over

Likely cause

All connections are in use

max_connections is reached, usually by idle connections an app never closes, or by queries that pile up.

Check it

sudo mysql -e "SHOW PROCESSLIST"

Read the fix: MySQL "ERROR 1040: Too many connections": get in, find who holds them, fix it

Not this?Start over

Likely cause

The client never reached SQL Server

The service is stopped, the instance name is wrong, TCP/IP is disabled, the port is different, or a firewall is in between.

Read the fix: SQL Server "A network-related or instance-specific error" (error 40, error 26): how to fix it

Not this?Start over

Likely cause

SQL Server refused the login

The client sees one message; the server's log has a State number that tells you why: a wrong password, a login that doesn't exist, SQL logins turned off, or a database you may not open.

Read the fix: SQL Server "Login failed for user" (error 18456): the state tells you why

Not this?Start over

Likely cause

Redis needs a password, and none was sent

The server has requirepass or ACL users set, and the client didn't authenticate. Find the password, then send it from redis-cli or the app's connection URL.

Read the fix: Redis "NOAUTH Authentication required": send the password, the right way for your client

Not this?Start over

Likely cause

Redis is at its memory limit

used_memory reached maxmemory, and the eviction policy doesn't allow removing keys. Choose a policy, set expiry times, or raise the limit carefully.

Check it

redis-cli INFO memory | grep -E "used_memory_human|maxmemory_human|maxmemory_policy"

Read the fix: Redis "OOM command not allowed when used memory > maxmemory": choose what to do when full

Not this?Start over

Likely cause

Redis can't save to disk, so it stops writes

The last background save failed: a full disk, a folder Redis can't write, or not enough memory to fork. The log says which.

Read the fix: Redis "MISCONF Redis is configured to save RDB snapshots": why writes stopped

Not this?Start over

Likely cause

mongod isn't running, or doesn't listen there

The server is stopped or failed to start, Node.js tried ::1 (IPv6) instead of 127.0.0.1, or bindIp keeps it local.

Check it

sudo systemctl status mongod --no-pager

Read the fix: MongoDB "connect ECONNREFUSED 127.0.0.1:27017": why it refuses, and how to fix it

Not this?Start over

Likely cause

The user isn't where the client looks, or the password is mangled

MongoDB users live in a database (often admin), set with authSource. Special characters in the password must be escaped in a connection string.

Read the fix: MongoDB "Authentication failed": the authSource is usually what's wrong

Not this?Start over

Likely cause

No listener at that address

The listener isn't running, listens on another host or port, or the network doesn't let you reach it.

Check it

lsnrctl status

Read the fix: Oracle "ORA-12541: no listener": start it, or connect to the address it really uses

Not this?Start over

Likely cause

The listener doesn't know that service name

You reached the listener, and the service you asked for isn't registered: a SID instead of a service name, a database or PDB that isn't open, or registration that hasn't happened.

Check it