Free tools Windows power users keep installed
One-click scans. No signup required.
Remote PostgreSQL access works only when every layer agrees: the server listens on a reachable interface, the TCP port is allowed through each firewall, pg_hba.conf matches the client address, database, and role, authentication succeeds, and the role has CONNECT privilege. Configure those controls in that order, keep the network scope narrow, and require TLS for connections that cross an untrusted network.
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 PostgreSQL remote access works
A PostgreSQL client does not connect directly to a database file. It opens a TCP connection to a server address and port, after which PostgreSQL applies its host-based authentication rules. A successful connection therefore has several independent gates:
As an Amazon Associate I earn from qualifying purchases.
| Layer | What it controls | Typical failure symptom |
|---|---|---|
| Listener | listen_addresses determines which server interfaces accept TCP connections. |
Connection refused, or the server is reachable only locally. |
| Routing and firewalls | Operating-system firewalls, cloud security groups, network ACLs, routers, and container port mappings must pass the PostgreSQL port. | Timeout or unreachable-host error. |
| Host-based authentication | pg_hba.conf matches connection type, database, role, client address, and authentication method. |
“No pg_hba.conf entry” or a rule that appears to be ignored. |
| Authentication | Password, certificate, or another configured identity method proves who the client is. | Password, certificate, or authentication failure. |
| Database authorization | The role needs CONNECT on the target database, followed by any required object privileges. |
Login succeeds, but access to the database or objects is denied. |
The default TCP port is 5432. If your installation uses another port, that value must be identical in PostgreSQL, every firewall or security group, and the client connection settings.
Choose the network path before changing PostgreSQL
Decide how the client will reach the server and record the exact server address, client address or CIDR, database name, and role. Prefer a private or otherwise controlled network path. A public address is not automatically unsafe, but it increases scanning and attack exposure and requires stricter firewall, authentication, monitoring, and certificate practices.
#1 Best Overall
| Path | Exposure | Operational complexity | TLS and audit considerations | Best fit |
|---|---|---|---|---|
| Private network or VPC | Limited to hosts that can route to the private address. | Requires private routing and network-policy management. | TLS is still appropriate when the network is not fully trusted; flow logs and database logs can be reviewed separately. | Applications and operators inside one organization or cloud network. |
| Direct public exposure | Internet-reachable if the address and port are advertised. | Simple connectivity, but the largest security and maintenance burden. | Require TLS, use a narrow allowlist, monitor authentication attempts, and avoid broad HBA rules. | Only when a controlled private path is unavailable and the exposure is deliberately accepted. |
| SSH, VPN, or a database proxy path | The database port can remain private while an authenticated tunnel or intermediary carries traffic. | More components and another failure point to operate. | TLS may terminate or pass through at the intermediary; document where encryption ends and retain connection logs. | Administrative access, segmented networks, or environments that prohibit public database ports. |
Do not begin by adding 0.0.0.0/0 to an HBA rule or opening the port to the world. First identify the smallest client host or subnet that genuinely needs access.
Step 1: Set the PostgreSQL listener
Find the active configuration
PostgreSQL reads listen_addresses from postgresql.conf. Package layouts differ by operating system, distribution, container image, and hosting service, so use the configuration file belonging to the running server rather than editing an unused sample file. From an administrative SQL session, you can inspect the active value:
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 →SHOW listen_addresses;
SHOW port;The default listen_addresses value is localhost. PostgreSQL documentation describes that default as allowing only local TCP loopback connections. A remote client cannot connect while the server listens solely on loopback.
Select an intentional address
Set the value to the server address that should accept connections, or to a deliberately selected comma-separated list of addresses. The special value * listens on all available interfaces. It can be useful in a controlled, multi-interface deployment, but it broadens the set of interfaces that can receive connection attempts; use it only when that exposure is intentional and firewalls enforce the real boundary.
# postgresql.conf
listen_addresses = '10.20.30.15'Use the server’s private address when clients are on the same private network. If you configure an address that is not assigned to the host, PostgreSQL may fail to start or fail to bind that interface.
Rank #2
Restart after changing the listener
Changing listen_addresses requires a PostgreSQL restart. The exact service-manager command depends on the operating system or hosting provider. After the restart, verify the running value with SHOW listen_addresses; and confirm that the service is listening on the intended address and port using the host’s normal socket-inspection tools.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsStep 2: Confirm and standardize the TCP port
PostgreSQL uses 5432 by default. Check the actual value before changing any firewall or client configuration:
SHOW port;If the server uses a custom port, place that same number in the operating-system firewall, cloud security group, network ACL, container publishing rule, connection string, and client command. A changed port setting also requires a restart. Do not assume that a successful local Unix-domain-socket connection proves that the TCP listener or remote port is correct; local socket connections can work even when TCP is disabled or blocked.
Step 3: Allow the network path
A valid pg_hba.conf record cannot make a blocked TCP port reachable. Permit only the client host or subnet at the PostgreSQL TCP port in every layer between the client and server:
- the server operating-system firewall;
- cloud security groups or equivalent instance policies;
- network ACLs, routers, and segmentation rules;
- container or orchestration port mappings, when PostgreSQL runs in a container;
- VPN, bastion, or proxy policy when traffic uses an intermediary.
For one fixed client, an allowlist containing that host is narrower than a subnet. For a managed application subnet, use its exact CIDR. Keep the rule protocol-specific (TCP) and avoid opening unrelated ports. If the client address is translated by NAT, the server may see the translated address rather than the workstation’s original private address; use the address visible at the PostgreSQL host when writing the HBA rule.
Recommended Free Tools
Step 4: Add a narrow pg_hba.conf rule
Understand the fields
Each host rule uses the fields TYPE DATABASE USER ADDRESS METHOD. A practical TLS-protected example is:
hostssl appdb appuser 203.0.113.25/32 scram-sha-256hostsslmatches TCP connections that use SSL/TLS.appdbis the only database matched by this record.appuseris the only role matched.203.0.113.25/32represents one IPv4 client address.scram-sha-256requires SCRAM password authentication.
Replace those example values with the real database, role, and client CIDR. For an approved private subnet, use that subnet’s exact CIDR instead of 0.0.0.0/0. If IPv6 clients are possible, add an intentional IPv6 rule with the correct IPv6 CIDR; an IPv4 record does not match an IPv6 source.
Put specific records before broad records
PostgreSQL examines HBA records sequentially for each connection attempt. The first matching record determines the result; it does not continue searching after an authentication failure. Place a database-and-role-specific rule above broader rules, and review existing entries for an earlier match that could change the outcome.
# Specific application access first
hostssl appdb appuser 203.0.113.25/32 scram-sha-256
# A broader rule, if genuinely required, comes later
hostssl all reporting_role 10.20.0.0/16 scram-sha-256Do not use trust for an internet-reachable rule. PostgreSQL describes trust as allowing anyone who can connect to log in as any PostgreSQL user without a password or other authentication. That setting may be suitable for a tightly controlled local development scenario, but it is not an appropriate substitute for authentication on a remote exposure.
Step 5: Choose authentication and enable TLS where needed
SCRAM password authentication
scram-sha-256 is a practical choice for password-based remote access when clients support it. Store a strong, unique secret for the role, rotate it through your normal secret-management process, and avoid putting it in shell history, source code, or shared configuration. Confirm that the client library or command-line tool supports SCRAM before enforcing it.
Certificate authentication
Certificate-based authentication can remove reusable passwords from the connection flow and can map client certificates to database roles. It requires a certificate authority, server and client certificate lifecycle, revocation or replacement procedures, and client software configured for certificates. It is a good fit when your organization already operates a managed PKI.
External identity methods
Other PostgreSQL authentication methods can integrate with an existing identity system, but they add deployment-specific dependencies and client requirements. Select them based on credential handling, rotation, client support, and the operational ability to recover from an identity-service outage. The HBA method must match what the client and server are actually configured to use.
Require TLS for remote connections
PostgreSQL has native TLS support. Enable ssl, install a server certificate and private key with the permissions required by your deployment, and use hostssl for rules that must be encrypted:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
# postgresql.conf
ssl = on
# pg_hba.conf
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 over that port. Encryption alone is not the same as certificate verification: configure clients to verify the server certificate according to your trust model, rather than merely allowing an encrypted but unverified connection. If you need to permit both encrypted and unencrypted traffic, separate the rules deliberately and understand which clients can match each one; for sensitive remote access, an explicit hostssl rule is clearer.
Step 6: Reload the right configuration
Edits to pg_hba.conf normally need a configuration reload, not a full restart. Run one of the following from an authorized SQL or server-management context:
SELECT pg_reload_conf();pg_ctl reload -D /path/to/data-directoryThe data-directory path and service command are installation-specific. Check the PostgreSQL log after reloading for syntax or permission errors. A reload that fails leaves the previous configuration in effect, so do not assume that a saved file has been accepted.
Changing listen_addresses or port requires a restart. Schedule that restart according to the service’s availability requirements and verify the listener afterward.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Step 7: Grant database access separately from HBA access
Passing HBA authentication proves the role’s identity; it does not grant entry to every database. The role also needs CONNECT on the target database:
GRANT CONNECT ON DATABASE appdb TO appuser;Grant only the object privileges the application or operator needs after connection, such as usage on a schema or selected table privileges. Keep administrative roles separate from application roles. If login succeeds but PostgreSQL reports a database authorization error, inspect the database’s CONNECT privilege and the role’s membership rather than widening the HBA address or changing authentication.
Connect from the client
Supply the server host, port, database, role, password or certificate, and SSL settings explicitly. A generic command-line shape is:
psql "host=10.20.30.15 port=5432 dbname=appdb user=appuser sslmode=verify-full"Use the hostname that matches the server certificate when sslmode=verify-full is enabled, and install the appropriate certificate authority in the client trust store. The exact connection-string syntax varies by driver, but the required concepts remain the same. Avoid embedding secrets directly in a command that may be retained in process history; use the driver’s supported secret store or environment mechanism according to your operating system’s security policy.
Diagnose failures by layer
| Observed result | Likely layer | Checks and corrective action |
|---|---|---|
| Timeout, unreachable host, or no response | Routing or firewall | Verify the destination address, route, security group, ACL, host firewall, VPN or tunnel state, and container port mapping. Confirm that TCP traffic reaches the server’s actual address. |
| Connection refused | Listener, port, or local policy | Check SHOW listen_addresses; and SHOW port;, confirm PostgreSQL is running, verify that the service is bound to the expected interface, and ensure the client is using the same port. |
| “No pg_hba.conf entry” | HBA match | Record the client address PostgreSQL reports, then compare it with the rule’s CIDR, database, role, and connection type. Check for an earlier rule and add the specific record above broader entries. Include an IPv6 rule if the client arrives over IPv6. |
| Password authentication failed | Credentials or authentication method | Confirm the role name, secret, password storage, client SCRAM support, and certificate configuration. Do not respond by changing the rule to trust. |
| SSL or certificate negotiation error | TLS configuration | Verify that the server has TLS enabled, the certificate and private key are readable with the required permissions, the client trusts the issuing authority, the hostname matches the certificate, and the HBA rule’s hostssl requirement matches the client’s SSL mode. |
| Login succeeds but database access is denied | Database or object privileges | Grant the role CONNECT on the intended database, then grant only the required schema and object privileges. |
Test from the same network location and with the same hostname family that the application uses. A local test on the database server can bypass the network firewall and therefore cannot prove that remote routing is correct.
Production hardening checklist
- Use a private address, VPN, SSH tunnel, or controlled proxy whenever practical.
- Allow only the required client host or subnet at the PostgreSQL TCP port.
- Keep
listen_addresseslimited to intended interfaces instead of using*by habit. - Use specific database and role matches in
pg_hba.conf, with narrow CIDRs and specific rules above broad ones. - Require
scram-sha-256, certificates, or an approved external identity method; never expose a remotetrustrule. - Use
hostssland client certificate verification when traffic crosses an untrusted network. - Grant
CONNECTand object privileges separately, following least privilege. - Record configuration changes, certificate rotation dates, role-secret rotation, and the approved source networks.
- Monitor PostgreSQL authentication failures and network flow logs so unexpected connection attempts are visible.
- After every change, test both the intended connection and an unauthorized source to ensure the boundary is doing what you expect.
What must be restarted, and what only needs a reload?
| Change | Action | Why |
|---|---|---|
pg_hba.conf rule |
Configuration reload | PostgreSQL can reread HBA records without stopping the server. |
listen_addresses |
Restart | The server must bind or release network interfaces during startup. |
port |
Restart | The TCP listener must be recreated on the new port. |
| Operating-system firewall or cloud security rule | Apply the network-policy change according to that platform | It is outside PostgreSQL’s configuration lifecycle. |
| Server certificate or key | Follow the deployment’s TLS reload or restart procedure | The running server must load the replacement credentials; the exact behavior depends on the installation. |
A repeatable validation sequence
- From the server, run
SHOW listen_addresses;andSHOW port;; confirm the values are intentional. - From the client network, verify that the chosen host resolves to the expected address and that the selected TCP port is reachable.
- Inspect
pg_hba.conffrom top to bottom, checking the first matching record for the client address, database, and role. - Reload after HBA edits and inspect PostgreSQL logs for parsing or permission errors.
- Connect with the intended SSL mode and credentials, using the exact database and role that the application will use.
- Confirm the role can connect to the target database but cannot access databases, schemas, or objects outside its grant.
- Test a denied source address and an invalid role to verify that the firewall and HBA boundaries reject them.
This sequence isolates network reachability, PostgreSQL matching, identity verification, and authorization instead of changing several controls at once.
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.
