HTTP TRACE behavior question

For security purposes, we need to ensure that an HTTP OPTIONS request does not return TRACE or other "potentially risky" HTTP options as identified by an NMAP scan (https://nmap.org/nsedoc/scripts/http-methods.html). My understanding is that NMAP sends HTTP requests to obtain this info, which will normally be proxied to the back end server, and that the best solution is to disable these HTTP methods on the back end server. If that isn't possible, we can intercept the requests and block them via ASM policy, HTTP profile configuration, or iRule, per https://support.f5.com/csp/article/K85840901.

In our case, we're having trouble getting this done on the back end server, so I'm looking into doing it on F5. I'm finding though, that some of my existing VIPs do NOT return TRACE when scanned with NMAP even though the servers DO have it enabled, and at least one other VIP DOES return TRACE when scanned. It seems like F5 is somehow blocking the requests on some VIPs, even though no ASM policy is applied, the HTTP client profiles are identical, and no iRules or LTM policies are applied. So either I'm missing something about how F5 is working, or there's something we're missing about the IIS8 configuration of our servers that is different.

Any ideas? Am I understanding things correctly, with the server normally the one that would respond to the HTTP requests generated by the NMAP scan, not the F5 unless it's explicitly configured to do so? I'll personally mail a delicious snack to anyone who can help.