diff --git a/docs/user_guide/phase.md b/docs/user_guide/phase.md
index a326496..5e30db8 100644
--- a/docs/user_guide/phase.md
+++ b/docs/user_guide/phase.md
@@ -16,7 +16,8 @@ The pingora-proxy HTTP proxy framework supports highly programmable proxy behavi
 Pingora-proxy allows users to insert arbitrary logic into the life of a request.
 ```mermaid
  graph TD;
-    start("new request")-->request_filter;
+    start("new request")-->early_request_filter;
+    early_request_filter-->request_filter;
     request_filter-->upstream_peer;
 
     upstream_peer-->Connect{{IO: connect to upstream}};
@@ -52,9 +53,12 @@ Pingora-proxy allows users to insert arbitrary logic into the life of a request.
 * The reason both `upstream_response_*_filter()` and `response_*_filter()` exist is for HTTP caching integration reasons (still WIP).
 
 
-### `request_filter()`
+### `early_request_filter()`
 This is the first phase of every request.
 
+This function is similar to `request_filter()` but execute before any other logic especially the downstream modules.
+
+### `request_filter()`
 This phase is usually for validating request inputs, rate limiting, and initializing context.
 
 ### `proxy_upstream_filter()`
diff --git a/docs/user_guide/phase_chart.md b/docs/user_guide/phase_chart.md
index a7d01d4..a6b6a4e 100644
--- a/docs/user_guide/phase_chart.md
+++ b/docs/user_guide/phase_chart.md
@@ -1,7 +1,8 @@
 Pingora proxy phases without caching
 ```mermaid
  graph TD;
-    start("new request")-->request_filter;
+    start("new request")-->early_request_filter;
+    early_request_filter-->request_filter;
     request_filter-->upstream_peer;
 
     upstream_peer-->Connect{{IO: connect to upstream}};