--- title: All Your GUCs in a Row: listen_addresses | daily.dev description: An in-depth look at PostgreSQL's listen_addresses parameter explains that it controls which TCP sockets the server binds to, not who can connect—that's... canonical: https://daily.dev/posts/all-your-gucs-in-a-row-listen-addresses-ro7mqsnfu twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: All Your GUCs in a Row: listen_addresses | daily.dev og:description: An in-depth look at PostgreSQL's listen_addresses parameter explains that it controls which TCP sockets the server binds to, not who can connect—that's... og:url: https://daily.dev/posts/all-your-gucs-in-a-row-listen-addresses-ro7mqsnfu og:image: https://api.daily.dev/og/posts/rO7MqSnFU.png og:image:alt: All Your GUCs in a Row: listen_addresses og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # All Your GUCs in a Row: listen_addresses **[Planet PostgreSQL](https://daily.dev/sources/planet-postgresql)** · 5 min read · 0 upvotes · 0 comments ## Summary An in-depth look at PostgreSQL's listen_addresses parameter explains that it controls which TCP sockets the server binds to, not who can connect—that's pg_hba.conf's job. It covers the postmaster's binding behavior at startup, why failures are per-entry and non-fatal, how to diagnose connection errors, and practical guidance: use * behind a real firewall, a specific private address on multi-homed hosts, or an empty string for socket-only local access. Also warns about floating VIP binding pitfalls in HA setups. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What is the difference between listen_addresses and pg_hba.conf in PostgreSQL? Listen_addresses controls which TCP sockets exist on the server, while pg_hba.conf controls who is allowed to use those sockets once they exist. A connection refused error means nothing is listening at that address or port, which points to listen_addresses, port, or a missing server; a "no pg_hba.conf entry for host" error means the socket accepted the connection but pg_hba.conf rejected it. _daily.dev surfaces practical postgresql configuration deep dives for engineers debugging connection refusals._ ### Why does PostgreSQL still accept connections after listen_addresses fails to bind one of its addresses? Binding failures in listen_addresses are per-entry and non-fatal: PostgreSQL logs a WARNING for each address it cannot bind and continues running on whatever addresses did succeed, only refusing to start if every entry fails with a FATAL error. This means a config like "127.0.0.1,*" can silently end up listening on loopback only if 0.0.0.0 fails with "Address already in use." _database engineers hardening postgresql network exposure can track these binding gotchas via daily.dev._ ### Why would a PostgreSQL server fail to accept connections on a floating VIP after failover? A socket can only be bound to an address the kernel currently holds, so listing a floating VIP in listen_addresses on a node that does not yet own that address fails with "Cannot assign requested address." The server still starts using any address that did bind, but after failover hands the VIP to that node, no socket exists behind it. The fix is binding to * or the interface's fixed address on HA nodes and letting the VIP route to it. _teams building postgresql high availability setups can follow config pitfalls like this through daily.dev._ ## Similar posts on daily.dev - [All Your GUCs in a Row: hba\_file](https://daily.dev/posts/all-your-gucs-in-a-row-hba-file-swywfe6vp) · Planet PostgreSQL · 0 upvotes · 0 comments - [All Your GUCs in a Row: config\_file](https://daily.dev/posts/all-your-gucs-in-a-row-config-file-53spmxdlx) · Planet PostgreSQL · 0 upvotes · 0 comments - [All Your GUCs in a Row: log\_connections, log\_disconnections, and log\_hostname](https://daily.dev/posts/all-your-gucs-in-a-row-log-connections-log-disconnections-and-log-hostname-othkylola) · Planet PostgreSQL · 0 upvotes · 0 comments - [All Your GUCs in a Row: max\_connections](https://daily.dev/posts/all-your-gucs-in-a-row-max-connections-32g7lgls2) · Planet PostgreSQL · 0 upvotes · 0 comments - [All Your GUCs in a Row: max\_wal\_senders](https://daily.dev/posts/all-your-gucs-in-a-row-max-wal-senders-kl8rlurbg) · Planet PostgreSQL · 0 upvotes · 0 comments --- Tags: [#security](https://daily.dev/tags/security), [#postgresql](https://daily.dev/tags/postgresql), [#networking](https://daily.dev/tags/networking) [View this post on daily.dev](https://daily.dev/posts/all-your-gucs-in-a-row-listen-addresses-ro7mqsnfu) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"All Your GUCs in a Row: listen_addresses","url":"https://daily.dev/posts/all-your-gucs-in-a-row-listen-addresses-ro7mqsnfu","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/all-your-gucs-in-a-row-listen-addresses-ro7mqsnfu"},"datePublished":"2026-08-24T01:02:01.362Z","dateModified":"2026-09-14T08:34:04.162Z","description":"An in-depth look at PostgreSQL's listen_addresses parameter explains that it controls which TCP sockets the server binds to, not who can connect—that's...","image":"https://media.daily.dev/image/upload/s--VDukGCjf--/f_auto/v1722860399/public/Placeholder%2002","thumbnailUrl":"https://media.daily.dev/image/upload/s--VDukGCjf--/f_auto/v1722860399/public/Placeholder%2002","isAccessibleForFree":true,"articleSection":"Planet PostgreSQL","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Planet PostgreSQL","logo":"https://media.daily.dev/image/upload/logos/placeholder.jpg","url":"https://daily.dev/sources/planet-postgresql"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/all-your-gucs-in-a-row-listen-addresses-ro7mqsnfu","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"security,postgresql,networking","timeRequired":"PT5M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Planet PostgreSQL","item":"https://daily.dev/sources/planet-postgresql"},{"@type":"ListItem","position":3,"name":"All Your GUCs in a Row: listen_addresses"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/all-your-gucs-in-a-row-listen-addresses-ro7mqsnfu#faq","mainEntity":[{"@type":"Question","name":"What is the difference between listen_addresses and pg_hba.conf in PostgreSQL?","acceptedAnswer":{"@type":"Answer","text":"Listen_addresses controls which TCP sockets exist on the server, while pg_hba.conf controls who is allowed to use those sockets once they exist. A connection refused error means nothing is listening at that address or port, which points to listen_addresses, port, or a missing server; a \"no pg_hba.conf entry for host\" error means the socket accepted the connection but pg_hba.conf rejected it. daily.dev surfaces practical postgresql configuration deep dives for engineers debugging connection refusals."}},{"@type":"Question","name":"Why does PostgreSQL still accept connections after listen_addresses fails to bind one of its addresses?","acceptedAnswer":{"@type":"Answer","text":"Binding failures in listen_addresses are per-entry and non-fatal: PostgreSQL logs a WARNING for each address it cannot bind and continues running on whatever addresses did succeed, only refusing to start if every entry fails with a FATAL error. This means a config like \"127.0.0.1,*\" can silently end up listening on loopback only if 0.0.0.0 fails with \"Address already in use.\" database engineers hardening postgresql network exposure can track these binding gotchas via daily.dev."}},{"@type":"Question","name":"Why would a PostgreSQL server fail to accept connections on a floating VIP after failover?","acceptedAnswer":{"@type":"Answer","text":"A socket can only be bound to an address the kernel currently holds, so listing a floating VIP in listen_addresses on a node that does not yet own that address fails with \"Cannot assign requested address.\" The server still starts using any address that did bind, but after failover hands the VIP to that node, no socket exists behind it. The fix is binding to * or the interface's fixed address on HA nodes and letting the VIP route to it. teams building postgresql high availability setups can follow config pitfalls like this through daily.dev."}}]} ```