Trying to figure out why environmental variables in haproxy.cfg aren't working in HA-Proxy version 1.5.2

on the command line, using Printenv I get a list of environmental variables like FE_PORT_8000_TCP_ADDR=

Which I need to use in the haproxy.cfg. According to this and the docs How can I use environment variables in haproxy.conf using $FE_PORT_8000_TCP_ADDR or ${FE_PORT_8000_TCP_ADDR} should work. However that is not working.

In Haporxy.cfg hardcoding DOES work, and accessed in a browser it shows as expected:

backend FE
   # balance     roundrobin
    server      FE1  maxconn 256

But environmental variable with same supposed value doesn't, in the browser it gives 503 Service Unavailable.

backend FE
   # balance     roundrobin
    server      FE1 $FE_PORT_8000_TCP_ADDR:8000  maxconn 256

Any ideas on what is being done wrong?

UPDATE: This person has what looks like the same issue How can I use environment variables in haproxy.conf

  • How are you starting haproxy? You're environment variables may be set for your login session but if you're starting HAProxy via an init script you'll need to set the environment variables there instead.
    – notpeter
    May 22 '15 at 5:50
  • @notpeter I'm starting it by hand. e.g if i do one at a time: echo $FE_PORT_8000_TCP_ADDR service haproxy start and the echo shows the output of the environmental var I'd sort of expect haproxy to be able to see it took.
    – TroyWorks
    May 22 '15 at 16:41

Since you're stopping/starting with the service command, you need to specify the environment variables in your init script (e.g. /etc/init.d/haproxy on ubuntu) not in your interactive terminal session where you're controlling the service (service haproxy start). You can verify the environment variables available to a specific pid in the proc filesytem. If you check yours for haproxy, it'll likely be only TERM and LANG, because that's the only environment which gets passed via service to the init script (manpage for service).

# cat /proc/$(pgrep haproxy)/environ

If instead of starting daemonized haproxy from the init script you directly run haproxy you'll likely see the behavior you're looking for:

# haproxy -f /etc/haproxy/haproxy.cfg

To solve this, edit the init script /etc/init.d/haproxy and set your variables there:

export FE_PORT_8000_TCP_ADDR=
  • aha! that was it. The trick for me is that the environmental vars are being set by docker (linked containers) so I can't currently as easily reexport them. Thank you!
    – TroyWorks
    May 22 '15 at 18:29
  • @TroyWorks what part of this worked for you? are you running your own version of haproxy? what image are you using if not? I am running into the same issue when running haproxy directly and I can see before I run the command that all the variables are set by the user starting it. Sep 17 '15 at 18:30
  • @mschuett how haproxy is started tells it what scope of environmental variables it has access to. the way notpeter suggested vs the daemon way I was doing allowed it to reach the context where variables set in cfg files could be picked up. I don't know more than that sorry, I'm not a sys-admin. stock haproxy, tried a few actually.
    – TroyWorks
    Sep 18 '15 at 2:23

Had the same problem. Fixed it by adding double quotes around the environment variable.

As explained here (2.3. Environment variables)

HAProxy's configuration supports environment variables. Those variables are interpreted only within double quotes. Variables are expanded during the configuration parsing. Variable names must be preceded by a dollar ("$") and optionally enclosed with braces ("{}") similarly to what is done in Bourne shell. Variable names can contain alphanumerical characters or the character underscore ("_") but should not start with a digit.


I had the same problem but on Debian 8 (Jessie) and setting it in /etc/init.d/haproxy did not work. I fixed it by setting the variable in /etc/default/haproxy like this (no export needed)


For more info see my question and answer about my issue.


Assuming the fact that the /etc/init.d/haproxy file contains the following fragments of code:



if [ -e /etc/default/${BASENAME} ]; then
    . /etc/default/${BASENAME}

, then a good solution for you will be to pass additional variables through the /etc/default/haproxy file instead.

... as mentioned by Johan Gov there as well: https://serverfault.com/a/841307/608437

  • ... also note that the export part is mandatory there as haproxy is started as a different process.
    – Teodor
    Jan 30 '21 at 23:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.