This context issue may have more to do with your Tomcat implementation and DNS/network configuration than SSC Server.  As a start, recheck your .fortify home folder path details to locate that app.properties.  I have seen cases where this folder was not generated if the system RAM was less than the SSC requirements.

• https://www.microfocus.com/documentation/fortify-software-security-center/2120/SSC_Help_21.2.0/index.htm#SSC_UG/A_FortifyHome.htm?Highlight=%22app.properties%22

• https://www.microfocus.com/documentation/fortify-webinspect/2120/Fortify_Sys_Reqs_21.2.0/index.htm 

Without sharing substantial Tomcat details here, you may need to check with Fortify Support.

• Fortify Support, Licensing Entitlements, & Downloads – https://support.microfocus.com/help/support-portal.html

• Support Resource Letter:  https://support.microfocus.com/kb/kmdoc.php?id=KM03074867

Running the service as a Docker container can result in this (docker run .. --network=host .. , preferring IPv4 in the container's java and changing the listeners to use 0.0.0.0 may help).

Another possible mistake is expecting one Linux machine such as WSL2 to have the same network with its co-guest such as Windows in a virtualized host such as Microsoft HyperV.  By default, the Windows co-guest does port-forward from its localhost to WSL2.  To set up additional port-forwarding from Windows's LAN IP address to WSL2, I could use "netsh interface portproxy".  It may be tricky as I could not reuse destination ports for other mappings.