Wrong host while sending requests

My setup:

Project created in IntelliJ with maven archetype

gatling version 3.3.0
gatling-maven-plugin version 3.0.4
scala-maven-plugin version 4.2.4

The application I want to test, is accessible via a stub which is running on another host.
Sometimes (not all the time) the first request to the application itself, after the stub requests, is sent to the correct URL but with the wrong host header which is causing problems.
That first request is a POST request and gets a redirect but instead of a redirect location to the application I am getting a redirect location to the stub.

So how is it possible that the host value can be different form the URL and how is it possible it differs between iterations (problem can also occur in first iteration)?
And is it maybe possible to set the host header?

My simplified script looks like this:

package pack

import io.gatling.core.Predef._
import io.gatling.http.Predef._

class RecordedSimulationInlog extends Simulation {

 val httpProtocol = http
  .baseUrl("https://<stub>")
  .proxy(Proxy("<proxy>", 8080))
  .inferHtmlResources(BlackList(""".*\.js""", """.*\.css""", """.*\.gif""", """.*\.jpeg""", """.*\.jpg""", """.*\.ico""", """.*\.woff""", """.*\.woff2""", """.*\.(t|o)tf""", """.*\.png""", """.*detectportal\.firefox\.com.*"""), WhiteList())
  .acceptHeader("text/html, image/gif, image/jpeg, */*")
  .acceptEncodingHeader("gzip, deflate")
  .acceptLanguageHeader("nl-NL")
  .userAgentHeader("Mozilla/5.0 (Windows NT 6.1; Win64; x64; Trident/7.0; rv:11.0) like Gecko")
  .connectionHeader("keep-alive")

val uri2 = "https://<application>"

 val scn = scenario("RecordedSimulationInlog")
  .exitBlockOnFail {
   repeat(20) {
    exec(session => session.reset )
    .exec(flushCookieJar)
    .exec(flushHttpCache)
    .exec(session => session.remove("gatling.http.referer"))
    .exec(http("request_0")
     .get("/"))
     .pause(3)
     .exec(http("request_1")
      .get("/?wa=wsignin1.0&wtrealm=<wtrealm>"))
     .pause(3)
     .exec(http("request_2")
      .post("/?wa=wsignin1.0&wtrealm=<wtrealm>")
      .header("Cache-Control", "no-cache")
      .formParam("wa", "wsignin1.0")
      .formParam("realm", "<realm>")
      .formParam("QueryString", "<QueryString>")
      .formParam("claim_registratieverelatiecode", "123456")
      .formParam("claim_authenticatiestelsel", "02"))
     .pause(3)
     .exec(http("request_3")
      .post(uri2 + "/signin-stub")
      .header("Cache-Control", "no-cache")
      .formParam("wa", "wsignin1.0")
      .formParam("wresult", "<wresult>"))
     .pause(1)
   }
  }

 setUp(scn.inject(atOnceUsers(1))).protocols(httpProtocol)
}

From console log:

POST https:///signin-stub
headers=
Connection: keep-alive
Accept: text/html, image/gif, image/jpeg, /
Cache-Control: no-cache
Accept-Language: nl-NL
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; Trident/7.0; rv:11.0) like Gecko
Referer: https:///signin-stub
cookie: ASP.NET_SessionId=5em2jnu02pyg0rhsv2lat4cf
host:
formBody=
wa: wsignin1.0
wresult:
proxy=HttpProxyServer{realm=null, securedPort=8080, securedAddress=/:8080, host=’’, port=8080}

The problem is solved. One of the formParams (wresult) needs to be XML decoded (> becomes >, < becomes <).
I found a function for it but it also transformed lt and gt (without the & and ;). That’s also the reason that in some cases the error/problem occurred because the lt and/or gt not always occur in the wresult value.
So the redirect to the stub instead off the application is not weird/unexpected in this case. What is weird/unexpected, however, is the host being the stubs. That threw me off.

No idea what could be wrong with the Host header, we would need you to provide a way for us to reproduce.