Cloudflare HTTP 522 with HaProxy

  • Dear all

    I'm running HaProxy 0.59_1 on pfsense 2.4.4_3 (i5, 16GB RAM, SSD).
    The sites are set up on various LXD VMs (hardware also i5, 16GB RAM, SSD).
    DNS: Cloudflare
    Web hosting: self (static public IP)

    The sites tested OK locally but via WAN
    I can't get rid of Cloudflare's HTTP error 522. ('reachable, but response too slow')

    I'm not sure if my HaProxy config is correct. (please see enclosed file)
    Any suggestions welcome.

    Thanks a bunch!
    HaProxy settings_(line_ending_WIN).txt

  • @tn1rpi3
    Nice manual config writeout.. though can you please include the haproxy.cfg from the bottom of the haproxy settings tab? It shows the 'actual' config used by haproxy, and should show if there are any 'logic errors' in the configuration and how the package combined the different (shared)frontend into 1 config file. Usually easier (for me at least) to make suggestions from there..

    Reading your writeout, it seems that you have 1 certificate for all websites, and thats okay, but i dont see you write any manually created acl's to check before the 'action use-backend ' is performed..? I guess haproxy is likely sending all traffic to the same backend as a result.. But anyhow, the haproxy.conf should show such missing 'logic rules'.

  • @PiBa said in Cloudflare HTTP 522 with HaProxy:


    Thanks for taking the time to sift through it. -
    You're right about acl's. There are none in the current config.

    Here's haproxy.cfg (renamed it to '.txt' for the upload to succeed).
    A brief look at it confirms that the lines referring to 'acl' are identical for all sites.

    So i figure I need to create correct 'default backend' acl's for all frontends.
    Would the following entry be correct for the shared frontend?
    Name Expression CS Not Value
    acl1 host matches x -
    ('x' =check, '-' =blank')

    Is there anything else along the way that needs attention?

  • @tn1rpi3
    I would not make the acl CaseSensitive. If someone writes http://12bFree.Com they should still be able to visit the website right?
    There is no need to select default-backend's in the shared-frontends and its probably better those it anyhow when using 1 certificate for all.
    But do also include the 'acl1' behind the use-backend action after defining the acl's.

    So something like this:

       moodleacl host matches - -
       use-backend moodle.12bfree.com_ipv4 if moodleacl

    And repeat that for the other sites.. Also if your only using 1 certificate for all, then it could be easier to read by configuring them all in 1 frontend in the webgui also but that depends a bit on personal preference.

    Other than that it can be nice to specify allowed ciphers to get a A+ rating on ssllabs with some settings like these: , you can manually add those on the settings tab in a advanced text field..

  • @PiBa I've changed the configuration as follows to include the ACLs (see .txt file)
    Alas, no availability via WAN. (reachable locally both via http and https)

    Could the problem have something to do with my apache2 config on the VMs?
    Originally, I set the sites up to use a self-signed certificate (before I went on to configure HaProxy).
    So the apache2 site.config files on the VMs still feature the paths to the self-signed certs.
    That doesn't seem right to me..

    EDIT: I just found out that my ISP changed my public IP address. No wonder it didn't work.
    I'll solve the issue with the ISP and then check again.

  • @tn1rpi3 Solved. Settings on pfsense haven proven quite correct thanks to PiBa's input. The router's correct IP address has been reassigned. Some misunderstanding on the ISP's side..
    All good now.

Log in to reply