Question

反缓存

anticache设置该选项后，它将删除可能引起服务器响应的Header（if-none-match和if-modified-since）304 not modified。当您要确保完全捕获HTTP交换时，这很有用。当您要确保服务器以完整的数据响应时，也经常在客户端重播期间使用它。

客户端重播

客户端重播可以做到：您提供了一个以前保存的HTTP对话，而mitmproxy则一个接一个地重播了客户端请求。请注意，mitmproxy会序列化请求，等待服务器的响应，然后再开始下一个请求。这可能与录制的对话不同，在录制的对话中，可能是同时发出请求的。

您可能希望将客户端重放与该anticache选项结合使用，以确保服务器响应完整的数据。

本地目录

map_local选项使您可以指定任意数量的模式，这些模式定义HTTP请求到本地文件或目录的重定向。获取本地文件而不是原始资源，然后透明地将其返回给客户端。

map_local模式看起来像这样：

|url-regex|local-path
|flow-filter|url-regex|local-path

• local-path是应提供给客户端的文件或目录。
• url-regex是应用于请求URL的正则表达式。它必须匹配才能进行重定向。
• flow-filter是一个可选的mitmproxy过滤器表达式 ，它另外限制将重定向的请求。

例子

图案 描述

• |example.com/main.js|~/main-local.js 替换example.com/main.js为~/main-local.js。
• |example.com/static|~/static 替换example.com/static/foo/bar.css为~/static/foo/bar.css。
• |example.com/static/foo|~/static 替换example.com/static/foo/bar.css为~/static/bar.css。
• |~m GET|example.com/static|~/static 替换example.com/static/foo/bar.css为~/static/foo/bar.css（但仅适用于GET请求）。

细节

如果local-path是一个文件，则将始终提供该文件。文件更改将立即反映出来，没有缓存。

如果local-path是目录，则使用url-regex将请求URL分为两部分，右侧的部分追加到local-path，不包括查询字符串。但是，如果url-regex包含一个正则表达式捕获组，则此行为会更改，并且将附加第一个捕获组（并且不会删除查询字符串）。特殊字符映射到_。如果找不到该文件，/index.html将附加该文件，然后重试。无法在原始指定目录之外遍历目录。

为了说明这一点，请考虑以下示例，该示例将对所有请求的映射example.org/css*到本地目录~/static-css。

                  ┌── url regex ──┬─ local path ─┐
map_local option: |example.com/css|~/static-css
                            │
                            │    URL is split here
                            ▼            ▼
HTTP Request URL: https://example.com/css/print/main.css?timestamp=123
                                               │                ▼
                                               ▼              query string is ignored
Served File:      Preferred: ~/static-css/print/main.css
                   Fallback: ~/static-css/print/main.css/index.html
                  Otherwise: 404 response without content

如果文件取决于查询字符串，则可以使用正则表达式捕获组。在此示例中，所有GET请求example.org/index.php?page=<page-name>都映射到~/static-dir/<page-name>：

                    flow
                  ┌filter┬─────────── url regex ───────────┬─ local path ─┐
map_local option: |~m GET|example.com/index.php\\?page=(.+)|~/static-dir
                            │                           │
                            │                           │ regex group = suffix
                            ▼                           ▼
HTTP Request URL: https://example.com/index.php?page=aboutus
                                                        │
                                                        ▼
Served File:                 Preferred: ~/static-dir/aboutus
                              Fallback: ~/static-dir/aboutus/index.html
                             Otherwise: 404 response without content

远程目录

map_remote选项使您可以指定任意数量的模式，这些模式定义HTTP请求URL中的替换，然后将其发送到服务器。将获取替代的URL，而不是原始资源，并且相应的HTTP响应将透明地返回给客户端。请注意，如果原始目标使用HTTP2，则替代目标也需要支持HTTP2，否则替代请求可能会失败。作为解决方法，您可以使用--no-http2标志启动mitmproxy以禁用HTTP2。 map_remote模式看起来像这样：

|flow-filter|url-regex|replacement
|url-regex|replacement

• flow-filter是可选的mpmproxy过滤器表达式 ，用于定义该map_remote选项适用于哪些请求。
• url-regex是有效的Python正则表达式，它定义了在请求的URL中要替换的内容。
• replace是被替换为的字符串文字。

该分离器是任意的，并且由第一字符定义。

例子

将所有以.jpg结尾的请求映射到https://www.wenjiangs.com/wp-content/uploads/2021/docimg15/18-5i1oxqrf0hp.jpg$|https://placedog.net/640/480?random

将所有GET请求从重新路由example.org到mitmproxy.org（|用作分隔符）：

|~m GET|//example.org/|//mitmproxy.org/

修改Body

modify_body选项使您可以指定任意数量的模式，这些模式定义流主体内的替换。modify_body模式看起来像这样：

/flow-filter/body-regex/replacement
/flow-filter/body-regex/@file-path
/body-regex/replacement
/body-regex/@file-path

• flow-filter是可选的mpmproxy过滤器表达式 ，用于定义替换适用的流。
• body-regex是有效的Python正则表达式，用于定义要替换的内容。
• replace是替换为的字符串文字。如果替换字符串文字以@开头@file-path，则将其视为读取替换的文件路径。

该分离器是任意的，并且由第一字符定义。

收到客户端请求或服务器响应时，将触发Modify挂钩。仅匹配的流组件会受到影响：因此，例如，如果在服务器响应上触发了修改挂钩，则替换仅在Response对象上运行，而Request则保持不变。您可以使用过滤器模式控制挂钩是在请求，响应还是两者上触发。如果您需要比这更细粒度的控制，则可以使用Flow组件上的替换API创建脚本很简单。

例子

更换foo用bar的请求的机构：

/~q/foo/bar

替换foo为从读取的数据~/xss-exploit：

mitmdump --modify-body :~q:foo:@~/xss-exploit

修改标题

modify_headers选项使您可以指定一组要修改的标题。可以添加新的Header，并且可以覆盖或删除现有的Header。 modify_headers模式看起来像这样：

/flow-filter/name/value
/flow-filter/name/@file-path
/name/value
/name/@file-path

• flow-filter是可选的mpmproxy过滤器表达式 ，用于定义要修改其Header的流。
• name是要设置，替换或删除的标题名称。
• value是要设置或替换的Header值。空值将删除名称为name的现有Header。如果值字符串文字以@开头@file-path，则将其视为从中读取替换内容的文件路径。

该分离器是任意的，并且由第一字符定义。

默认情况下，现有Header会被覆盖。可以使用过滤器表达式进行更改。

收到客户端请求或服务器响应时，将触发Modify挂钩。仅匹配的流组件会受到影响：因此，例如，如果在服务器响应上触发了修改挂钩，则替换仅在Response对象上运行，而Request则保持不变。您可以使用过滤器模式控制挂钩是在请求，响应还是两者上触发。如果您需要比这更细粒度的控制，则可以使用Flow组件上的替换API创建脚本很简单。

例子

将所有请求的HostHeader设置example.org为（Host替换现有Header）：

/~q/Host/example.org

将HostHeader设置example.org为所有不具有HostHeader的请求：

/~q & !~h Host:/Host/example.org

将User-AgentHeader设置为从~/useragent.txt所有请求读取的数据（User-Agent替换现有Header）：

/~q/Host/@~/useragent.txt

从所有请求的Header中删除现有的Host：

/~q/Host/

代理验证

在允许用户使用代理之前要求用户进行身份验证。身份验证Header已从流中剥离，因此不会传递给上游服务器。目前，仅支持HTTP基本身份验证。代理身份验证选项与透明，袜子或反向代理模式不兼容。

服务器端重播

server_replay选项使我们可以从保存的HTTP对话中重播服务器响应。为此，我们使用一组试探法将传入的请求与保存的响应进行匹配。默认情况下，当将传入请求与重播文件的响应进行匹配时，我们将排除请求Header，并且仅使用URL和请求方法进行匹配。这在大多数情况下都有效，并且可以在请求Header自然变化的情况下（例如，使用不同的用户代理）重播服务器响应。

有很多方法可以自定义匹配的启发式方法，包括指定要包含的Header，要排除的请求参数等。这些选项收集在server_replay前缀下-有关详细信息，请参阅内置文档。

响应刷新

仅重放服务器响应而不进行修改通常会导致意外的行为。例如，记录对话时将来的cookie超时可能在重播时是过去的。缺省情况下，mitmproxy在将服务器响应发送到客户端之前刷新服务器响应。该日期，过期和最后修改头都更新为具有相同的相对时间，因为他们曾在录音的时间偏移。因此，如果它们在录制时已过去，那么它们将在重放时已过去，反之亦然。Cookie的到期时间以类似的方式更新。

您可以通过将server_replay_refresh选项设置为来 关闭此行为false。

重放以反向代理模式记录的会话

如果您以反向代理模式捕获了会话，则要重播会话，您仍然必须指定服务器URL，否则可能会收到错误消息：“客户端请求中的HTTP协议错误：无效的HTTP请求形式（预期的授权或绝对… ）'。

在重播期间，当客户端的请求与先前记录的请求匹配时，相应的已记录响应将由mitmproxy进行简单重播。否则，不匹配的请求将转发到上游服务器。如果不需要转发，则可以使用–kill（-k）开关来防止这种情况。

stickyauth

·stickyauth选项类似于sticky cookie选项，因为一旦看到HTTP 授权Header，它们就会被简单地重播到服务器。这足以允许您通过代理使用HTTP基本身份验证来访问服务器资源。请注意，mitmproxy尚不支持HTTP Digest身份验证的重播。

Sticky cookies

stickycookie设置该选项后，mitmproxy会将服务器最近设置的cookie添加到任何无cookie的请求中。考虑一种设置cookie以便在身份验证后跟踪会话的服务。使用粘性cookie，您可以启动mitmproxy，并像通常使用浏览器一样对服务进行身份验证。身份验证后，您可以通过mitmproxy来请求经过身份验证的资源，就好像它们未经身份验证一样，因为mitmproxy会自动将会话跟踪cookie添加到请求中。除其他外，这使您可以编写脚本与经过身份验证的资源进行交互（使用诸如wget或curl的工具），而不必担心身份验证。

粘性cookie与客户端重播一起使用时特别强大-您可以记录一次身份验证过程，并且每次需要与受保护的资源进行交互时，只需在启动时重播它即可。

流媒体

默认情况下，mitmproxy将读取整个请求/响应，对其执行任何指示的操作，然后将消息发送给另一方。在下载或上传大文件时，这可能会出现问题。启用流传输后，消息正文不会在代理上缓冲，而是直接发送到服务器/客户端。HTTPHeader在发送前仍处于完全缓冲状态。

通过在stream_large_bodies选项中指定大小限制来启用请求/响应流 。

自定义流

您还可以使用脚本来精确自定义流式传输的请求或响应。请求/响应应该被标记为通过设置流.stream属性True：

"""
Select which responses should be streamed.

Enable response streaming for all HTTP flows.
This is equivalent to passing `--set stream_large_bodies=1` to mitmproxy.
"""

def responseheaders(flow):
    """
    Enables streaming for all responses.
    This is equivalent to passing `--set stream_large_bodies=1` to mitmproxy.
    """
    flow.response.stream = True

网络套接字

stream_websockets选项为websocket启用类似行为。启用WebSocket流传输后，可能会更改WebSocket消息有效负载的部分代码不会对发送到服务器的实际有效负载产生任何影响，因为帧会立即转发到服务器。与不存储正文的HTTP流相反，消息有效负载仍将存储在WebSocket流中。

上游证书

当mitmproxy收到发往受SSL保护的服务的连接时，它将在读取请求数据之前冻结该连接，并建立与上游服务器的连接以“嗅探”其SSL证书的内容。获得的信息-通用名称和主题备用名称-然后用于生成拦截证书，该证书将发送给客户端，以便连接可以继续。

即使客户端仅指定了IP地址而不是主机名，这种相当复杂的小舞蹈也使我们能够无缝地生成正确的证书。这也意味着我们不需要嗅探其他数据即可在透明模式下生成证书。

默认情况下，上游证书嗅探是打开的，并且可以选择使用upstream_cert选项关闭。