You're misunderstanding the way HSTS (HTTP Strict Transport Security) works. If you enable this header, then client browsers that support HSTS should refuse to make plain HTTP connections to your domain (and potentially all sub-domains) on any port.
If a user attempts to connect to http://www.example.com/ (implied port 80) then the browser will automatically change to this https://www.example.com/ (implied port 443)
If the user attempts to connect to http://www.example.com:8000/ (or any port other than 80/443) then the browser will automatically change this to https://www.example.com:8000/ (or whichever port was specified).
If you enable HSTS, then you must be prepared to serve all HTTP traffic for your domain over a secure connection.
I don't know what you've done to supposedly work around this, but whether it works or not it's a violation of the HSTS specification and, even if it works now, is likely to stop working in the future.
The correct answer is to properly configure port 8000 to serve traffic over a secure connection.
See the RFC, section 8.3, for further details
Edit: Just an extra point of clarification in case this matters in your scenario;
Note that HSTS doesn't care which server, or IP address you use. Once you start serving the header for a particular domain from anywhere, you must serve all HTTP traffic to that domain on any server over a secure connection.
The flip side to this is that if you have a shared server hosting multiple domains, the domains that aren't serving up the HSTS header can continue to operate over plain HTTP from the same server. HSTS cares about the domain, not the server.
So if the service you have on port 8000 for some reason absolutely can't operate over HTTPS, then another option would be to host it on a different domain, or sub-domain. If you choose to use a sub-domain you need to be sure that the HSTS header has not been set to include sub-domains.