Skip to main content
ezhupa
Staff
Staff
April 8, 2026

Technical Tip: Real Server HTTP URL healthcheck not working after upgrade

  • April 8, 2026
  • 0 replies
  • 354 views
Description This article describes issues with the HTTP URL health check not working after the upgrade.
Scope FortiGate.
Solution

When configuring Virtual Servers on the FortiGate, a common practice is to configure a health check for the real servers to monitor how healthy the connection is, so the FortiGate can forward the traffic accordingly.

In some cases, this health check can be configured as an HTTP type, for example:

 

config firewall ldb-monitor
    edit "HTTP_Healthcheck"
        set type http
        set interval 30
        set timeout 10
        set retry 3
        set http-get "http://www.test.com/home"
    next
end

 

This health check is then configured on the Virtual Server configuration:

 

config firewall vip
    edit "TEST_VirtualServer"
        set type server-load-balance
        set server-type http
        set extip XX.XX.XX.XX
        set extintf "any"
        set extport <portnr>
            config realservers
                edit 1
                    set ip <server_IP1>
                    set port <portnr>
                    set healthcheck enable
                    set monitor "HTTP_Healthcheck"
                next
                edit 2
                    set ip <server_IP2>
                    set port <portnr>
                    set healthcheck enable
                    set monitor "HTTP_Healthcheck"
                next
            end
    next

 

After an upgrade to FortiOS v7.4.10+/7.6.5+, this health check monitor might have issues and be marked as down.

A solution in this case would be to use set http-get "www.test.com/home" instead of set http-get 'http://www.test.com/home' without the 'http://' scheme.

 

Verify the health check status via the CLI using the following command:

 

diagnose firewall vip virtual-server real-server list

 

Since the type is already mentioned in the load balancer configuration, there is no need for the 'http://' part. URI/path can be used in this case, or switch to a TCP health check monitor if the full URL is needed for the real server to respond.

 

Related article:

Troubleshooting Tip: Troubleshooting real server health check monitoring