To allow a game server, development workstation, or operations tool to reach PostgreSQL remotely, configure every layer of the connection: make PostgreSQL listen on the intended interface, allow the TCP port through network controls, add a matching pg_hba.conf rule, authenticate the role, and grant it CONNECT on the database. A failure at any one layer prevents access. Keep the listener, client CIDR, firewall rule, and HBA entry as narrow as the deployment permits.
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
How remote PostgreSQL access works
A remote connection is accepted only after several independent checks succeed. The client must be able to route to the server address; the server must be listening on that address and port; host and network firewalls must pass the traffic; pg_hba.conf must select an authentication rule for the client, database, and role; authentication must succeed; and the role must have permission to connect to the database.
As an Amazon Associate I earn from qualifying purchases.
| Layer | What it controls | Typical failure |
|---|---|---|
| Routing and firewall | Whether packets can reach the PostgreSQL host and TCP port | Timeout, rejected connection, or unreachable host |
listen_addresses and port |
Which server interfaces accept PostgreSQL TCP traffic and on which port | Connection refused because nothing is listening on the requested address |
pg_hba.conf |
Which client address, database, role, and authentication method are allowed | “No pg_hba.conf entry” error |
| Authentication | Whether the supplied password, certificate, or external identity is valid | Password or certificate authentication failure |
| Database privilege | Whether the authenticated role may enter the target database | “Permission denied” or a failed CONNECT check |
PostgreSQL documentation describes the default listener as localhost, which permits only local loopback TCP connections. Remote TCP/IP connections therefore require an appropriate value for listen_addresses.
Prepare the addresses, database, and role
Identify the server address
Choose the address that remote clients should use. A private or VPC address is preferable for game services, administration tools, and internal APIs. If the server has several interfaces, record the specific interface or addresses that should accept PostgreSQL traffic. Do not expose an internet-facing interface merely because it is convenient.
#1 Best Overall
Identify the client CIDR
Record the source address as PostgreSQL will see it. A single fixed host can be represented as a /32 IPv4 CIDR, such as 203.0.113.25/32 in documentation examples. For an internal subnet, use that subnet’s exact CIDR. If a proxy, VPN, NAT gateway, or container network changes the source address, the HBA rule must match the address visible to PostgreSQL, not the workstation’s original private address.
Record the database and role
Decide exactly which database and PostgreSQL role need access. A game service should normally use a dedicated role and database rather than a superuser or a shared operator account. Keep these values available while editing the firewall and HBA configuration so that all layers describe the same connection.
Configure the PostgreSQL listener
Set listen_addresses
Open the active postgresql.conf and set listen_addresses to the required server address or a deliberately selected list:
listen_addresses = '10.20.0.15'Use * only when listening on every available interface is intentional and the surrounding firewall controls are equally deliberate:
listen_addresses = '*'The default value, localhost, accepts only local loopback TCP connections. Changing listen_addresses requires a PostgreSQL restart; a configuration reload alone does not make the new listener active.
Confirm the TCP port
PostgreSQL uses TCP port 5432 by default. Check the active port setting rather than assuming the default:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Rank #2
port = 5432If the installation uses another port, use that number consistently in PostgreSQL, the operating-system firewall, cloud security groups or network ACLs, container mappings, and every client connection string. Changing port also requires a restart.
Find the active configuration file
Package layouts differ by operating system and hosting provider. From a local administrative session, query the server for its active file location instead of editing an unused sample:
SHOW config_file;Also verify that the service you restart is the instance containing the target database. Multiple PostgreSQL versions or clusters on one host can each have a different listener and HBA file.
Open only the required network path
A correct HBA rule cannot make a blocked TCP port reachable. Permit the selected client host or subnet to reach the PostgreSQL TCP port in every control between client and server:
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →- the server’s operating-system firewall;
- cloud security groups or equivalent security policies;
- network ACLs and router rules;
- container, virtual-machine, or orchestration port mappings; and
- VPN, bastion, or proxy policy when those are part of the path.
There is no universal firewall command because the syntax and policy model vary by operating system, cloud, and container platform. The rule should specify the server’s PostgreSQL port and the smallest source CIDR that needs access. Do not open 5432 to 0.0.0.0/0 as a shortcut for diagnosing a connection.
Add a narrow pg_hba.conf rule
Understand the fields
Each HBA record follows the fields TYPE DATABASE USER ADDRESS METHOD. The record must match the connection type, target database, role, and client address before its authentication method is applied.
| Field | Example | Purpose |
|---|---|---|
| TYPE | hostssl |
Allows TCP connections and, in this example, requires SSL/TLS |
| DATABASE | appdb |
Limits the rule to one database |
| USER | appuser |
Limits the rule to one role |
| ADDRESS | 203.0.113.25/32 |
Limits the source host or subnet |
| METHOD | scram-sha-256 |
Chooses the authentication mechanism |
Use a specific rule
For one client host using TLS and SCRAM authentication, an example is:
hostssl appdb appuser 203.0.113.25/32 scram-sha-256Replace every example value with the real database, role, and client CIDR. For a private application subnet, use that subnet’s exact CIDR rather than a universal address such as 0.0.0.0/0. Keep separate rules for separate applications or operator groups when they need different credentials or permissions.
Respect rule order
HBA records are examined from top to bottom, and the first matching record controls the attempt. Put a narrow rule before a broader rule. A broad earlier rule can silently select an unintended authentication method, while a later specific rule will never be reached. Review surrounding records for an existing reject, trust, or broad host entry before adding a new one.
Choose authentication and protect the connection
SCRAM password authentication
scram-sha-256 is a practical default for password-based access when the clients support it. Store the role secret in the game service’s secret manager or protected configuration, rotate it on a schedule, and avoid placing it in source control or public logs.
Certificate authentication
Certificate-based authentication can remove shared passwords and tie access to issued client certificates. It requires certificate issuance, renewal, revocation, and client support, so it fits environments that already operate a certificate lifecycle.
External identity methods
External identity or directory methods can centralize account policy, but deployment fit and client support vary. Confirm the PostgreSQL authentication method, role mapping, and operational ownership before selecting one for a production game service.
Free tools Windows power users keep installed
One-click scans. No signup required.
| Method | Credential handling | Rotation and operations | Best fit |
|---|---|---|---|
scram-sha-256 |
Role password stored by the client securely | Rotate role secrets and update clients | Most application connections with SCRAM-capable clients |
| Certificate authentication | Private key and client certificate | Issue, renew, and revoke certificates | Deployments with an established certificate program |
| External identity | Managed by the selected identity system | Depends on directory, mapping, and provider operations | Organizations standardizing database access on an external identity service |
Never use trust for internet-reachable access
PostgreSQL documents that trust lets anyone who can connect log in as any PostgreSQL user without a password or other authentication. It can be useful for narrowly controlled local development, but it is unsafe for a remotely reachable rule. If an old broad trust entry matches before your secure rule, reorder or remove it.
Require TLS when appropriate
PostgreSQL has native TLS support. Enable ssl, install a server certificate and private key with the permissions required by the PostgreSQL service, and use hostssl for rules that must be encrypted:
ssl = on
hostssl appdb appuser 203.0.113.25/32 scram-sha-256The server listens for normal and SSL connections on the same TCP port and negotiates with the client. A client configured for certificate verification must trust the issuing certificate chain and verify the server name according to the deployment’s trust model. Do not treat encryption as proof of authorization: TLS and HBA matching are separate from database privileges.
Reload or restart the correct service
Reload HBA and other reloadable settings
After editing pg_hba.conf, reload the running instance:
Recommended Free Tools
SELECT pg_reload_conf();Alternatively, use the instance’s pg_ctl reload command or the service-reload action supplied by the operating system or hosting platform. A reload applies HBA edits without disconnecting existing sessions.
Restart listener changes
Restart PostgreSQL after changing listen_addresses, port, or settings that the server reads only at startup. Schedule the restart according to the service’s availability requirements and verify that the intended cluster, rather than another installed version, restarted successfully.
Ensure the role can connect to the database
Passing HBA authentication does not automatically grant database access. The role must have the database-level CONNECT privilege:
GRANT CONNECT ON DATABASE appdb TO appuser;Grant only the target database access required by the application or operator. After the connection succeeds, object privileges such as schema, table, sequence, or function permissions are evaluated separately. A role may therefore authenticate successfully and still receive an authorization error when it accesses an object.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuteConnect from the client and verify each layer
Supply all connection parameters
Use the server address, active port, database, role, and the selected password or certificate. For a TLS client that verifies the server certificate, a connection string can look like this:
psql "host=10.20.0.15 port=5432 dbname=appdb user=appuser sslmode=verify-full"Use the SSL mode appropriate for the deployment. If the client is configured to require verification, provide the trusted certificate authority and a hostname that matches the server certificate. Avoid putting passwords directly in shell history or process arguments.
Test from the real network location
Run the test from the same host, subnet, container, VPN, or bastion path used by the application. A local test can pass while a remote test fails because the source address, firewall route, or DNS result differs. Confirm the client’s observed source address before changing the HBA CIDR.
Validate the result
- A timeout indicates that routing or a firewall is blocking the path; inspect network controls before changing authentication.
- A refusal usually means the address or port has no listening PostgreSQL service, or a firewall is actively rejecting it.
- A successful login followed by a database permission error points to
CONNECTor object privileges. - A successful TLS negotiation confirms encryption, not that the role is authorized for every database object.
Troubleshoot by the error you see
| Symptom | Likely layer | Checks and correction |
|---|---|---|
| Connection timed out | Routing or firewall | Verify the server address, route, operating-system firewall, cloud security policy, network ACL, and container mapping. Confirm that the client source CIDR is allowed. |
| Connection refused | Listener or port | Check the active listen_addresses and port, restart after changing either, and ensure the client uses the same port allowed by the firewall. |
No pg_hba.conf entry |
HBA match | Check the client address as seen by PostgreSQL, database name, role, connection type, and rule order. Add a narrow matching record and reload. |
| Password authentication failed | Role secret or method | Confirm the role name, secret, selected HBA method, and client support for SCRAM. Do not respond by replacing the rule with trust. |
| TLS or certificate error | SSL configuration or client verification | Confirm ssl, certificate and key installation, hostssl matching, trusted issuer, server name, and client SSL mode. |
| Authenticated but cannot open database | Database privilege | Grant the required CONNECT privilege on the target database, then check schema and object privileges separately. |
Change one layer at a time and retest. Broadening the listener, firewall, CIDR, and authentication method simultaneously makes it difficult to identify the actual fault and can leave an unintended exposure behind.
Choose an exposure pattern
| Pattern | Network exposure | Operational complexity | TLS and audit considerations | Failure isolation |
|---|---|---|---|---|
| Direct public exposure | PostgreSQL is reachable from a public address; risk is highest | Lowest path complexity, but strict firewall, patching, monitoring, and credential controls are essential | Require TLS with hostssl; monitor authentication and network events |
Database is directly affected by internet scans and attacks |
| Private-network access | Limited to a VPC, private subnet, or internal route | Requires private routing and network policy | Use TLS where credentials or data cross untrusted internal segments | Private routing and security groups reduce unrelated exposure |
| SSH, VPN, or proxy path | PostgreSQL remains off the public interface; clients enter through a controlled path | More components, accounts, keys, and availability dependencies | Decide whether TLS terminates at the database, proxy, or both; audit the gateway and database | Gateway failure can block access without exposing the database directly |
For a production game backend, private-network access or a controlled VPN, SSH, or proxy path generally reduces exposure compared with a publicly reachable listener. The right choice depends on routing, operations, client compatibility, and where your organization can enforce logging and access policy.
Production checklist
- Use a private or tightly controlled server address whenever possible.
- Set
listen_addressesto the required interface list, not automatically to*. - Keep the PostgreSQL port consistent across the server, firewall, network policy, and client.
- Allow only the required client host or subnet through every firewall and network control.
- Write HBA records with the exact database, role, and CIDR; place specific rules before broad ones.
- Prefer
scram-sha-256or an appropriate certificate or external identity method. - Never use
truston a remotely reachable rule. - Enable TLS and use
hostsslwhen the deployment requires encrypted connections. - Grant only the required
CONNECT, schema, and object privileges. - Reload after HBA edits and restart after listener or port changes.
- Test from the application’s actual network path and record the source address PostgreSQL sees.
- Monitor failed authentication, rotate credentials or certificates, and periodically remove obsolete firewall and HBA entries.
What to remember
Remote access is not enabled by one setting. PostgreSQL must listen on a reachable interface, the selected port must pass the network controls, an ordered HBA record must match the client and require suitable authentication, and the role must have CONNECT on the database. Keep every value specific to the real server, client CIDR, database, and role, then diagnose failures in that same order.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
