In a Windows PowerShell 5.1 session, an earlier component can change process-local .NET networking state. An ordinary Start-Job background job provides a separate PowerShell process for a later web operation.

$job = Start-Job -ArgumentList $uri, $proxyUri -ScriptBlock {
    param($destination, $intermediary)
    $response = Invoke-WebRequest -Uri $destination `
        -Proxy $intermediary -UseBasicParsing -TimeoutSec 30
    $response.Content
}
try {
    Receive-Job -Job $job -Wait -ErrorAction Stop
}
finally {
    Remove-Job -Job $job
}

uri and proxyUri are application-supplied values. For a public HTTP test, the HTTP proxy list supplies candidate intermediary addresses; keep the chosen endpoint steady when comparing processes. Provide any needed proxy credentials through the intended job inputs and request parameters as well. A live web session object from the parent is not automatically reused.

The job has its own session state; load required functions or modules there. Its output crosses a process boundary, so returning the content deliberately is simpler than assuming a deserialized response behaves like the original live object.

Start-ThreadJob uses another execution model and does not provide the same process isolation. A separate process also does not repair an invalid proxy endpoint or a network-wide policy. Use this boundary when shared process state is the relevant difference.

Related articles