hba_file is a pointer, not a policy. It tells the server where to find pg_hba.conf, the file that actually decides who may connect, from where, as whom, and by what authentication method. About those decisions hba_file has nothing to say. Its entire job is the address.
It is a string, its context is postmaster so it is fixed at server start, and it can be set in postgresql.conf. Its default is pg_hba.conf in the data directory, which is where initdb writes one when it creates the cluster. You will very rarely have a reason to change it, and the reasons you might are all variations on wanting the authentication file to live somewhere other than inside the data directory.
The distinction that trips everyone
The single most useful thing to understand here is the difference between the file and the parameter that points at it, because they have completely different update rules.
Changing the contents of pg_hba.conf, adding a rule, tightening a method, allowing a new network, requires only a reload. You edit the file and signal the server with pg_ctl reload, SELECT pg_reload_conf(), or a plain SIGHUP, and the new rules take effect for subsequent connections without interrupting anything. No restart, no dropped sessions.
Changing the location, which is to say changing hba_file itself, requires a restart, because it is a postmaster-context parameter read only at startup. This is where the confusion bites: people conflate “I changed my authentication configuration” with “I changed hba_file,” and reach for a restart they do not need, or expect a location change to take effect on reload when it will not. You edit the rules constantly and reload; you touch hba_file almost never and restart.
Knowing which file is actually live
The default is the data directory, but your packages may have moved it. The Debian-family packaging in particular keeps pg_hba.conf under /etc/postgresql/, alongside the rest of the cluster’s configuration, and sets hba_file to match. The result is a reliable way to lose an afternoon: you edit a pg_hba.conf, reload, and nothing changes, because the file you edited is not the file the server is reading.
The server will tell you the truth if you ask it. SHOW hba_file;, or a query against pg_settings, returns the exact path the running server loaded, and that is the only path worth editing. Check it before assuming you know where the file is.
Check before you reload
There is a specific hazard with authentication configuration that does not apply to most files: a mistake in it can lock you out of the server you would use to fix it. A pg_hba.conf with a syntax error, or a well-formed rule that shuts out your own access, becomes a live problem the moment the server reads it.
PostgreSQL gives you a pre-flight check for exactly this. The pg_hba_file_rules view, available since PostgreSQL 10, shows the parsed contents of pg_hba.conf one row per rule, with an error column that is non-null on any line the server could not process. Critically, it reports what is in the file on disk, not what the server currently has loaded, which is what makes it a vetting tool: you query it after editing and before issuing the reload, confirm every line parses and the rules say what you meant, and only then signal the server. It reads by superuser only, and a botched line shows up with just its line number and the error. Treat a reload of pg_hba.conf as something you look at through this view first.
The summary
Leave hba_file at its default unless you have a deliberate reason to keep the authentication file outside the data directory, in which case set it and remember the change costs a restart. The daily work is not in this parameter; it is in the file it points to. Find that file with SHOW hba_file, edit it, vet the result through pg_hba_file_rules, and apply it with a reload. The parameter is the address. The house, and the lock on its door, is pg_hba.conf.