In production, requests from the world will typically not hit the container (e.g. Tomcat) directly, but rather an Apache httpd server that forwards them to a Tomcat instance. The original hostname in the request is than typically preserved in a header (X-Forwarded-For) which is picked up by the HST to match the proper host in the hst:hosts configuration.
It’s hard to say what goes wrong in your situation. Maybe the deployment of the site as ROOT.war goes wrong? But then still it’s weird that it does work initially.
the question is, where in code occurs the disable of the console?
I thinks the problem comes from apache (ibm) and the https configuration. The site works well, but maybe some check related with https/http from apache side make the console disable. As i mention before, in PREPRODUCTION enviroment, we hit directly the IBM and the console always up.
I’ll try to reproduce the problem in a sandbox enviorment with https in apache, but… what trigger the disable of the console?
What do you mean exactly with “disable of the console”? Do you mean you cannot access the Console application anymore? (e.g. locally running as http://localhost:8080/cms/console). Or something else?
Maybe to approach all of this differently: what are you trying to achieve in the first place? Like Jasper already said, Websphere is not part of our supported stack, so although it “runs great” as your first post said, there are probably some details that don’t work well, or only work with some Websphere-specific configuration.
You could try to stick as close to the default setup in Tomcat as possible. So try not to deploy the site as ROOT.war (that isn’t supported in version 13 anymore anyway). And ideally use Tomcat, which is the supported option and works out of the box.