iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
To allow a remote PostgreSQL connection, configure every layer in order: make PostgreSQL listen on a reachable server address, expose the correct TCP port through host and network firewalls, add a narrowly scoped pg_hba.conf rule for the client address, authenticate the role, and grant that role CONNECT on the database. If the connection crosses an untrusted network, enable TLS and require it with hostssl. A change in any one layer cannot compensate for a failure in another.
How remote PostgreSQL access works
A remote client must pass several independent gates:
Recommended Free Tools
- Network address: the client must route to the server address you choose.
- Listener: PostgreSQL must bind to that server interface instead of only the local loopback address.
- Port path: the operating-system firewall, cloud security group, network ACL, load balancer, or container mapping must permit the PostgreSQL TCP port.
- Host-based authentication: an ordered rule in
pg_hba.confmust match the connection type, database, role, and client CIDR. - Authentication: the password, certificate, or external identity presented by the client must be valid.
- Authorization: the role must have
CONNECTon the database and whatever schema or object privileges the application needs.
The default PostgreSQL TCP port is 5432. The default listen_addresses value is localhost, which accepts only local loopback TCP connections. PostgreSQL documentation describes the consequence directly: remote TCP/IP connections are not possible until the server starts with an appropriate listen_addresses value.
For production, prefer a private network or a controlled tunnel over exposing a database directly to the internet. Never use trust for an internet-reachable rule: PostgreSQL states that anyone who can connect can then log in as any PostgreSQL user without a password or other authentication.
#1 Best Overall
Before changing configuration
Record the connection you actually intend to permit
- Server address: use a private or VPC address when the client is inside the same controlled network. If a public address is unavoidable, restrict every network control to the known client host or subnet.
- Client CIDR: record the source address PostgreSQL will see. A single host is normally written as
203.0.113.25/32; a private subnet uses its exact CIDR, such as10.20.30.0/24. - Database: identify the exact database name, rather than allowing every database with
allunless that broad access is intentional. - Role: identify the application or operator role that should connect. Do not create a broad rule simply because a different role was used during testing.
- Port: confirm whether the installation still uses
5432. A custom port must be used consistently in PostgreSQL, firewalls, security groups, port mappings, and client connection strings.
Find the active configuration files
Package layouts and managed services place postgresql.conf and pg_hba.conf in different directories. Use the server itself to identify the active files:
SHOW config_file;
SHOW hba_file;
SHOW listen_addresses;
SHOW port;Run these statements in an existing local administrative session. If you cannot connect locally, use the configuration location documented by your operating system or hosting provider rather than assuming a package-specific path.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Step 1: Choose a safe network design
| Path | Network exposure | Operational complexity | TLS and auditing considerations | Typical use |
|---|---|---|---|---|
| Private-network access | Limited to a VPC, private subnet, data-center network, or other controlled route | Requires routing and private firewall rules, but avoids public exposure | Still use TLS when traffic crosses a network you do not fully trust; retain firewall and database logs | Applications and administrators within the same organization’s network |
| Direct public exposure | Internet-reachable address, even if a firewall narrows the source range | Simple routing, but the largest attack surface and most monitoring burden | Require TLS, strict CIDRs, strong authentication, patching, and continuous review | Only when a private path or controlled proxy is not available |
| SSH, VPN, or database proxy path | Database can remain private while clients enter through a controlled intermediary | More components and credentials to operate; tunnel or proxy failures are a separate layer | Centralized access logs and policy enforcement are possible; verify where TLS terminates and whether the onward connection is encrypted | Temporary administration, segmented environments, and organizations with an established access gateway |
The safest design is the narrowest path that meets the application’s needs. A VPN or proxy does not remove the need for a correct listener, port, HBA rule, authentication method, and database privilege; it only changes how the client reaches the server.
Step 2: Configure the PostgreSQL listener
Set listen_addresses
Open the active postgresql.conf and set listen_addresses to the server address the client should reach:
listen_addresses = '10.20.30.15'You may specify a deliberately selected comma-separated list when PostgreSQL must listen on more than one interface. The special value * listens on all available interfaces; use it only when that exposure is intentional and the firewall rules are equally deliberate. Leaving the value at localhost allows only local TCP loopback connections.
This setting is read at server start, so changing it requires a PostgreSQL restart. A reload alone will not make a new network interface begin accepting connections.
Confirm the port
PostgreSQL uses port 5432 by default. Keep the default if there is no operational reason to change it:
Rank #2
port = 5432If the installation uses another port, write that exact value into every dependent control and client setting. Changing port also requires a restart.
Verify the listener after the restart
From a local administrative session, check the effective values:
SHOW listen_addresses;
SHOW port;At the operating-system level, verify that a PostgreSQL process is listening on the intended address and port. The exact inspection command differs by operating system, container runtime, and managed service, so use the platform’s documented socket or service inspection tool.
Step 3: Open only the required network path
Permit the client address or subnet to reach the PostgreSQL TCP port in every control between client and server:
- the server operating-system firewall;
- a cloud security group or equivalent instance firewall;
- network ACLs and subnet routing;
- container or orchestration port mappings; and
- any load balancer, bastion, or proxy policy in front of PostgreSQL.
For example, if the server listens on 10.20.30.15:5432 and one application host is 10.20.40.25, permit only that source host to that destination port. Do not open 0.0.0.0/0 merely to test whether PostgreSQL works. A firewall rule should be narrowed before the service is exposed, not after a successful test.
A correct pg_hba.conf record cannot make a blocked TCP port reachable. Conversely, an open port does not grant database access unless HBA, authentication, and privileges also succeed.
Step 4: Add a narrow pg_hba.conf rule
Understand the fields
Each HBA record follows the fields TYPE DATABASE USER ADDRESS METHOD. A typical encrypted rule for one application host is:
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitcheshostssl appdb appuser 203.0.113.25/32 scram-sha-256hostsslmatches TCP connections that use TLS.appdblimits the rule to one database.appuserlimits it to one role.203.0.113.25/32permits one client IPv4 address. Replace it with the actual source CIDR PostgreSQL sees.scram-sha-256requires password authentication using SCRAM.
For a private subnet, use its exact CIDR instead of a world-wide range:
hostssl appdb appuser 10.20.40.0/24 scram-sha-256Put specific rules before broad rules
PostgreSQL examines HBA records sequentially for each connection attempt, and the first matching record determines the result. Place a host-specific rule above a subnet rule, and a subnet rule above any intentionally broad fallback. A later secure rule cannot override an earlier rule that already matches.
Inspect existing entries for an earlier reject, a broader password rule, or a local-only rule that changes the outcome you expect. Keep comments beside rules documenting the owner, purpose, and permitted network so that a future administrator can remove stale access safely.
Avoid broad or unsafe patterns
Do not use 0.0.0.0/0 or ::/0 unless unrestricted source access is a consciously accepted design. Do not use trust for remote exposure. The trust method allows any reachable host to log in as any PostgreSQL user selected by the client, with no password or other authentication. If a temporary diagnostic rule is unavoidable, restrict it to a private, isolated path and remove it immediately after testing.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Step 5: Choose authentication and enable TLS
Password authentication with SCRAM
scram-sha-256 is the usual password-based choice for a new remote rule. Ensure the role has a password stored in a form compatible with SCRAM and provide that password through the client’s protected secret mechanism, not in shell history or source code. Rotate the credential according to your organization’s process.
Certificate authentication
Certificate authentication can remove long-lived shared passwords and can bind a client identity to a certificate authority policy. It requires issuing, distributing, revoking, and rotating certificates and configuring every client that connects. Use it when your deployment already operates a certificate lifecycle and clients support the required PostgreSQL certificate method.
External identity methods
External identity methods can centralize authentication, but they add dependency on the identity service and require compatible PostgreSQL, operating-system, and client configuration. Evaluate credential handling, rotation, outage behavior, and client support before selecting one.
Require TLS with hostssl
PostgreSQL has native TLS support. Enable ssl, install a server certificate and private key with the permissions required by the PostgreSQL service, and use a hostssl HBA record for connections 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 about SSL. A hostssl rule still requires the client to be configured for TLS and, where appropriate, to verify the server certificate against the deployment’s trusted certificate authority. Encryption without certificate verification can leave a client vulnerable to connecting to an impersonating endpoint.
If you deliberately permit both encrypted and unencrypted traffic, use separate rules and understand which clients can select the weaker path. For sensitive remote access, require TLS rather than relying on client preference.
Step 6: Reload or restart in the correct order
Use a reload after editing pg_hba.conf; use a restart after changing listen_addresses or port.
- Validate the edited files using the checks provided by your PostgreSQL installation or managed service.
- Reload configuration with one supported method, such as
SELECT pg_reload_conf();orpg_ctl reload. A platform service reload is also valid when the platform documents it. - Restart PostgreSQL when a listener or port change was made. Plan for the service interruption and confirm that dependent applications reconnect.
- Check the effective settings and server logs after the operation.
pg_reload_conf() reports whether PostgreSQL accepted the request to reload; it does not prove that every line in an edited file expresses the rule you intended. Confirm the effective listener and test the exact remote path.
Free tools Windows power users keep installed
One-click scans. No signup required.
Step 7: Grant database access separately from HBA access
Passing HBA authentication is not sufficient. The role must also have the CONNECT privilege on the target database:
GRANT CONNECT ON DATABASE appdb TO appuser;Grant only the database access required by the application or operator. After connecting, the role may still need schema, table, sequence, function, or default-privilege grants; those object permissions are separate from the network and HBA decision. Avoid granting superuser status merely to make a connection test pass.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Step 8: Connect with explicit client settings
Supply the same server address and port configured in the listener and firewall, along with the exact database and role:
psql "host=10.20.30.15 port=5432 dbname=appdb user=appuser sslmode=verify-full"Use an SSL mode appropriate to your certificate and trust model. When certificate verification is not yet configured, a less strict mode may help isolate a TLS setup problem, but do not treat that as a production security setting. Return to certificate verification before exposing the connection to an untrusted network.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
For an SSH, VPN, or proxy design, connect to the address and port presented by that path while preserving the same database name, role, HBA scope, and authentication requirements. Document whether TLS is end-to-end or terminates at the intermediary.
Troubleshoot by the layer that failed
The client times out
- Confirm the client has a route to the server address.
- Check the operating-system firewall, cloud security group, network ACL, container mapping, and any intermediary policy.
- Confirm PostgreSQL is listening on the intended non-loopback address and port after a restart.
- Check that the client is using the actual port; a custom port mismatch often looks like a blocked service.
A timeout normally indicates routing or filtering before PostgreSQL can evaluate pg_hba.conf.
The client reports “no pg_hba.conf entry”
- Record the client IP shown in the PostgreSQL error and compare it with the HBA CIDR.
- Check the exact database and role spelling.
- Check whether the connection is plain TCP or TLS;
hostsslmatches SSL connections, while a non-SSL attempt will not match it. - Review rules from top to bottom for an earlier match or reject.
- Reload the configuration after editing and confirm the server read the intended file.
Authentication fails
Verify the role’s password or certificate, the client’s SSL mode, certificate trust chain, and the authentication method named by the matching HBA rule. A successful TCP handshake does not prove that the supplied secret is valid.
Login succeeds but the database is rejected
Grant CONNECT on the requested database and reconnect. If login succeeds but queries fail, inspect schema and object privileges rather than changing network rules.
TLS negotiation or certificate verification fails
Confirm that ssl is enabled, the server certificate and private key are readable by PostgreSQL with the required permissions, the client trusts the issuing certificate authority, and the hostname used by the client matches the certificate identity when verification is enabled. Ensure the HBA rule is hostssl and that the client is actually requesting TLS.
The change appears to have no effect
Use SHOW config_file; and SHOW hba_file; to ensure you edited the active files. Determine whether the change needed a reload or a restart, check the PostgreSQL log for parse errors, and verify that a managed service did not overwrite the local file from its own configuration interface.
Production hardening checklist
- Use a private address, VPN, SSH tunnel, or controlled proxy whenever practical.
- Permit only the required client host or subnet at the network firewall and in
pg_hba.conf. - Keep database, role, and CIDR-specific rules above broader rules.
- Use
scram-sha-256, certificate authentication, or an appropriately integrated external identity method; never use remotetrust. - Require TLS with
hostsslfor traffic that crosses an untrusted or shared network. - Configure clients to verify the server certificate when your certificate trust model supports it.
- Grant
CONNECTand object privileges separately, and grant no more than the application needs. - Record who owns each remote rule, why it exists, and when it should be reviewed or removed.
- Monitor failed authentication, unexpected source addresses, firewall changes, and certificate or credential expiry.
- Retest after PostgreSQL upgrades, network changes, certificate rotation, and firewall policy changes because package paths, service commands, and managed-platform behavior vary.
What to remember
Remote PostgreSQL access is a chain, not a single switch. Set listen_addresses deliberately, keep the port path narrow, match the real client CIDR with an ordered HBA rule, authenticate with a secure method, require TLS where appropriate, reload or restart according to the setting changed, and grant CONNECT separately. Diagnose failures in that same order: routing and firewalls first, then listener, HBA matching, authentication, and finally database authorization.
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.
