Explain the execution flow of NGINX's request processing phases?

Internally, NGINX processes every request through a fixed sequence of eleven phases, and most custom logic - whether from core directives or third-party modules - hooks into one of these phases rather than running arbitrary, unordered code.

The phases relevant to most configurations, in order, are: post-read (right after headers are parsed), server-rewrite (rewrites at the server level), find-config (selects the matching location block), rewrite (location-level rewrites, where the rewrite directive and return operate), post-rewrite, preaccess, access (where allow/deny and auth checks run), post-access, try-files, content (where the actual response is generated - static file, proxy, or another content handler), and finally log.

Understanding this order explains behavior that otherwise looks surprising - for instance, why a rewrite in one location can cause NGINX to re-enter find-config with a new URI, effectively restarting part of the phase sequence, or why access checks always run before content is generated regardless of where in the config file the allow/deny directives are written.

flowchart LR
  A[post-read] --> B[server-rewrite]
  B --> C[find-config]
  C --> D[rewrite]
  D --> E[post-rewrite]
  E --> F[preaccess]
  F --> G[access]
  G --> H[post-access]
  H --> I[try-files]
  I --> J[content]
  J --> K[log]