In reverse proxy mode, mitmproxy accepts standard HTTP requests and forwards
them to the specified upstream server. This is in contrast to
<a href="@!urlTo("upstreamproxy.html")!@">upstream proxy mode</a>, in which
mitmproxy forwards HTTP proxy requests to an upstream proxy server.

<table class="table">
    <tbody>
        <tr>
            <th width="20%">command-line</th> <td>-R <i>schema</i>://hostname[:port]</td>
        </tr>
    </tbody>
</table>

Here, **schema** is one of http, https, http2https or https2http. The latter
two extended schema specifications control the use of HTTP and HTTPS on
mitmproxy and the upstream server. You can indicate that mitmproxy should use
HTTP, and the upstream server uses HTTPS like this:

	http2https://hostname:port

And you can indicate that mitmproxy should use HTTPS while the upstream
service uses HTTP like this:

	https2http://hostname:port


### Host Header

In reverse proxy mode, mitmproxy does not rewrite the host header. While often useful, this
may lead to issues with public web servers. For example, consider the following scenario:

    $ python mitmdump -d -R http://example.com/ &
    $ curl http://localhost:8080/

    >> GET https://example.com/
        Host: localhost:8080
        User-Agent: curl/7.35.0
        [...]

    << 404 Not Found 345B

Since the Host header doesn't match <samp>example.com</samp>, an error is returned.<br>
There are two ways to solve this:
<ol>
    <li>Modify the hosts file of your OS so that example.com resolves to 127.0.0.1.</li>
    <li>
        Instruct mitmproxy to rewrite the host header by passing <kbd>&#8209;&#8209;setheader&nbsp;:~q:Host:example.com</kbd>.
        However, keep in mind that absolute URLs within the returned document or HTTP redirects will cause the client application
        to bypass the proxy.
    </li>
</ol>