What a Nginx access line looks like
The Combined sample below is fed verbatim into the engine to produce every parser on this page.
203.0.113.45 - - [03/Jul/2026:14:22:15 +0300] "GET /api/health HTTP/1.1" 200 2 "-" "kube-probe/1.29"
198.51.100.23 - - [03/Jul/2026:14:22:19 +0300] "POST /login HTTP/1.1" 401 231 "https://example.com/" "Mozilla/5.0 (X11; Linux x86_64; rv:126.0) Gecko/20100101 Firefox/126.0" Detected fields
The engine classified this sample as freeform and consolidated 11 fields across 2 lines. Fields marked literal were identical on every sample line, so they are baked into the pattern as anchors rather than captured.
- ip1 : ipv4
- _lit1 : literal · literal
- _lit2 : literal · literal
- timestamp : timestamp
- method : http_method
- path : path
- quoted_string : quoted_string · literal
- status : http_status
- number : number
- url : url
- user_agent : user_agent
Regex (named capture groups)
# sample: 203.0.113.45 - - [03/Jul/2026:14:22:15 +0300] "GET /api/health HTTP/1.1" 200 2 "-" "kube-probe/1.29"
# groups: ip1=203.0.113.45, timestamp=03/Jul/2026:14:22:15 +0300, method=GET, path=/api/health, status=200, number=2, url=-, user_agent=kube-probe/1.29
^(?<ip1>\d{1,3}(?:\.\d{1,3}){3}) - - \[(?<timestamp>\d+/[A-Za-z]+/\d+:\d+:\d+:\d+ \+\d+)\] "(?<method>[^"]*) (?<path>(?:/[^\s"']*|[A-Za-z]:[^\s"']*)) HTTP/1\.1" (?<status>\d{3}) (?<number>-?\d+(?:\.\d+)?) "(?<url>[^"]*)" "(?<user_agent>[^"]*)"$ - note the message tail diverges across lines and could not be split into stable fields — the trailing per-token literal group(s) are positional word-slices of that unstructured message, not stable fields
Grok pattern (Logstash / Elastic)
# custom patterns
NGINX_NOTDQUOTE [^"]*
%{IPV4:ip1} - - \[%{HTTPDATE:timestamp}\] "%{WORD:method} %{UNIXPATH:path} HTTP/1\.1" %{INT:status} %{NUMBER:number} "%{NGINX_NOTDQUOTE:url}" "%{NGINX_NOTDQUOTE:user_agent} - note constant field "quoted_string" embedded as literal anchor "HTTP/1.1" (varying=false)
- note field "url" (url): samples do not all match %{URI}; using %{NGINX_NOTDQUOTE} instead
- note custom patterns emitted — save the '# custom patterns' block to a file in your patterns_dir
Wazuh decoder (OS_Regex XML)
<!--
Generated by LogForge - Wazuh decoder (OS_Regex dialect, not PCRE)
sample: 203.0.113.45 - - [03/Jul/2026:14:22:15 +0300] "GET /api/health HTTP/1.1" 200 2 "-" "kube-probe/1.29"
test with: /var/ossec/bin/wazuh-logtest
-->
<decoder name="nginx-freeform">
<prematch>^\d+.\d+.\d+.\d+ </prematch>
</decoder>
<decoder name="nginx-freeform">
<parent>nginx-freeform</parent>
<regex>^(\d+.\d+.\d+.\d+) - - [(\d+/\w+/\d+:\d+:\d+:\d+ \p\d+)] "(\w+) (\S+) HTTP/1.1" (\d+) (\d+) "(\.+)" "(\.+)"</regex>
<order>srcip, timestamp, method, path, status, number, url, user_agent</order>
</decoder>
<!-- ============================================================
ALERT RULE (starter) — put this in a RULES file, e.g.
/var/ossec/etc/rules/local_rules.xml. Decoders and rules live
in SEPARATE files. The rule matches the decoder above through
<decoded_as>; set <level> and add <field>/<match> conditions so
it alerts only on the events you care about. Rule ids 100000+
are the user range — change them if they collide with yours.
============================================================ -->
<group name="nginx,">
<rule id="100000" level="3">
<decoded_as>nginx-freeform</decoded_as>
<description>nginx: srcip=$(srcip) url=$(url) status=$(status)</description>
</rule>
<!-- Example — a higher-level alert gated on one field (uncomment and edit):
<rule id="100001" level="10">
<if_sid>100000</if_sid>
<field name="status">^5\d\d$</field>
<description>nginx: a server-error response from $(status)</description>
</rule>
-->
</group>
- note no stable literal prefix found — <prematch> anchors on the leading field pattern; tighten it for your environment
- note field "ip1" mapped to Wazuh conventional field "srcip"
- note field "url": free-text capture (\.+) bounded by a quote anchor — OS_Regex greediness may over-consume if the anchor repeats
- note field "user_agent": free-text capture (\.+) bounded by end of line — OS_Regex greediness may over-consume if the anchor repeats
- note constant field "quoted_string" embedded as literal anchor "HTTP/1.1"
- note added a starter alert <rule> (level 3, matched to the decoder via <decoded_as>) — put it in a RULES file (not the decoders file), set the level, and add <field>/<match> conditions; the commented example child rule shows the pattern
- note decoder order and prematch specificity may need site-specific tuning (other decoders in your ruleset can shadow these) — validate with /var/ossec/bin/wazuh-logtest
Wazuh's OS_Regex is not PCRE — a bare . is a literal dot and \. matches any character.
Test Wazuh OS_Regex patterns →
rsyslog template / liblognorm rulebase
version=2
# nginx — liblognorm v2 rulebase (generated by LogForge)
# Usage with rsyslog (mmnormalize runs liblognorm):
# module(load="mmnormalize")
# action(type="mmnormalize" rulebase="/etc/rsyslog.d/nginx.rb" useRawMsg="on")
# Literal "%" is escaped as "%%"; raw tabs are written as \x09.
rule=nginx:%ip1:ipv4% - - [%timestamp:char-to{"extradata":"]"}%] "%method:word% %path:word% HTTP/1.1" %status:number% %number:number% "%url:char-to{"extradata":"\""}%" "%user_agent:char-to{"extradata":"\""}%"
- note trailing literal "\"" reconstructed from line 1
- note field "timestamp": samples do not uniformly match engine type "timestamp"; using a generic parser
- note chosen parser types: ip1=ipv4, timestamp=char-to(]), method=word, path=word, status=number, number=number, url=char-to("), user_agent=char-to(")
Splunk
# props.conf (search-time extraction)
[<REPLACE_WITH_SOURCETYPE>]
EXTRACT-logforge = (?<ip1>\d{1,3}(?:\.\d{1,3}){3}) - - \[(?<timestamp>\d+/[A-Za-z]+/\d+:\d+:\d+:\d+ \+\d+)\] "(?<method>[^"]*) (?<path>(?:/[^\s"']*|[A-Za-z]:[^\s"']*)) HTTP/1\.1" (?<status>\d{3}) (?<number>-?\d+(?:\.\d+)?) "(?<url>[^"]*)" "(?<user_agent>[^"]*)"
# Quick search-time test in SPL:
# | rex field=_raw "(?<ip1>\\d{1,3}(?:\\.\\d{1,3}){3}) - - \\[(?<timestamp>\\d+/[A-Za-z]+/\\d+:\\d+:\\d+:\\d+ \\+\\d+)\\] \"(?<method>[^\"]*) (?<path>(?:/[^\\s\"']*|[A-Za-z]:[^\\s\"']*)) HTTP/1\\.1\" (?<status>\\d{3}) (?<number>-?\\d+(?:\\.\\d+)?) \"(?<url>[^\"]*)\" \"(?<user_agent>[^\"]*)\"" - note regex: the message tail diverges across lines and could not be split into stable fields — the trailing per-token literal group(s) are positional word-slices of that unstructured message, not stable fields
- note EXTRACT-<class> names must be unique within a sourcetype stanza — rename EXTRACT-logforge if you already use that class for this sourcetype
- note a timestamp field was detected: this EXTRACT only makes it a searchable field. To set the event _time at index time, add TIME_PREFIX and TIME_FORMAT to this props.conf stanza (TIME_FORMAT uses Splunk strptime, e.g. %Y-%m-%dT%H:%M:%S) — this generator does not guess the strptime format.
ES ingest
PUT _ingest/pipeline/nginx
{
"description": "LogForge-generated ingest pipeline for nginx",
"processors": [
{
"grok": {
"field": "message",
"patterns": [
"%{IPV4:ip1} - - \\[%{HTTPDATE:timestamp}\\] \"%{WORD:method} %{UNIXPATH:path} HTTP/1\\.1\" %{INT:status} %{NUMBER:number} \"%{NGINX_NOTDQUOTE:url}\" \"%{NGINX_NOTDQUOTE:user_agent}"
],
"pattern_definitions": {
"NGINX_NOTDQUOTE": "[^\"]*"
}
}
}
]
} - note grok: constant field "quoted_string" embedded as literal anchor "HTTP/1.1" (varying=false)
- note grok: field "url" (url): samples do not all match %{URI}; using %{NGINX_NOTDQUOTE} instead
- note grok: custom patterns emitted — save the '# custom patterns' block to a file in your patterns_dir
- note test in Kibana Dev Tools with: POST _ingest/pipeline/nginx/_simulate (supply a docs[] array whose _source.message holds a sample line)
Graylog
# Grok patterns to add under System > Grok Patterns:
# (Graylog needs these custom patterns installed globally BEFORE the rule/extractor below will work.)
# NGINX_NOTDQUOTE [^"]*
# --- Graylog processing pipeline rule (primary) ---
# Paste under System > Pipelines > Manage rules, then attach the rule to a pipeline stage.
rule "nginx-parse"
when
has_field("message")
then
let gp = grok(pattern: "%{IPV4:ip1} - - \\[%{HTTPDATE:timestamp}\\] \"%{WORD:method} %{UNIXPATH:path} HTTP/1\\.1\" %{INT:status} %{NUMBER:number} \"%{NGINX_NOTDQUOTE:url}\" \"%{NGINX_NOTDQUOTE:user_agent}", value: to_string($message.message), only_named_captures: true);
set_fields(gp);
end
# --- Graylog import-ready extractor JSON (secondary) ---
# Save as a .json file and import under System > Inputs > (input) > Manage extractors > Actions > Import extractors.
{
"extractors": [
{
"title": "nginx",
"extractor_type": "grok",
"converters": [],
"order": 0,
"cursor_strategy": "copy",
"source_field": "message",
"target_field": "",
"extractor_config": {
"grok_pattern": "%{IPV4:ip1} - - \\[%{HTTPDATE:timestamp}\\] \"%{WORD:method} %{UNIXPATH:path} HTTP/1\\.1\" %{INT:status} %{NUMBER:number} \"%{NGINX_NOTDQUOTE:url}\" \"%{NGINX_NOTDQUOTE:user_agent}",
"named_captures_only": true
},
"condition_type": "none",
"condition_value": ""
}
],
"version": "5.0.0"
} - note grok: constant field "quoted_string" embedded as literal anchor "HTTP/1.1" (varying=false)
- note grok: field "url" (url): samples do not all match %{URI}; using %{NGINX_NOTDQUOTE} instead
- note grok: custom patterns emitted — save the '# custom patterns' block to a file in your patterns_dir
- note 1 custom grok pattern(s) (NGINX_NOTDQUOTE) must be installed globally first under System > Grok Patterns — see the block at the top of the output
- note primary artifact is the processing-pipeline rule; the extractor JSON is an equivalent import-ready alternative for the classic extractor UI
Datadog
logforge_rule %{ipv4:ip1} - - \[%{date("dd/MMM/yyyy:HH:mm:ss Z"):timestamp}\] "%{word:method} %{notSpace:path} HTTP/1\.1" %{integer:status} %{number:number} "%{notSpace:url}" "%{data:user_agent} - note emitted rule name is "logforge_rule"; rename it to match your "nginx" convention if desired
- note constant field "quoted_string" embedded as literal anchor "HTTP/1.1" (varying=false)
- note paste this line into a Grok Parser processor in a Datadog Log Pipeline; matchers are anchored left-to-right and rule whitespace matches log whitespace. Complex or multi-shape logs may need Helper Rules.
Fluent Bit
[PARSER]
Name nginx
Format regex
Regex ^(?<ip1>\d{1,3}(?:\.\d{1,3}){3}) - - \[(?<timestamp>\d+/[A-Za-z]+/\d+:\d+:\d+:\d+ \+\d+)\] "(?<method>[^"]*) (?<path>(?:/[^\s"']*|[A-Za-z]:[^\s"']*)) HTTP/1\.1" (?<status>\d{3}) (?<number>-?\d+(?:\.\d+)?) "(?<url>[^"]*)" "(?<user_agent>[^"]*)"$
Time_Key timestamp
Time_Format %d/%b/%Y:%H:%M:%S %z
# Fluentd <parse> block:
# <parse>
# @type regexp
# expression /^(?<ip1>\d{1,3}(?:\.\d{1,3}){3}) - - \[(?<timestamp>\d+\/[A-Za-z]+\/\d+:\d+:\d+:\d+ \+\d+)\] "(?<method>[^"]*) (?<path>(?:\/[^\s"']*|[A-Za-z]:[^\s"']*)) HTTP\/1\.1" (?<status>\d{3}) (?<number>-?\d+(?:\.\d+)?) "(?<url>[^"]*)" "(?<user_agent>[^"]*)"$/
# time_key timestamp
# time_format %d/%b/%Y:%H:%M:%S %z
# </parse>
- note regex: the message tail diverges across lines and could not be split into stable fields — the trailing per-token literal group(s) are positional word-slices of that unstructured message, not stable fields
- note Time_Key set to "timestamp"; Time_Format "%d/%b/%Y:%H:%M:%S %z" is a best-effort strptime derived from the sample shape — verify it against your data (Fluent Bit uses %L for fractional seconds and %z for numeric offsets)
Vector
[transforms.nginx_parse]
type = "remap"
inputs = ["REPLACE_WITH_SOURCE"]
source = '''
. |= parse_regex!(.message, r'(?P<ip1>\d{1,3}(?:\.\d{1,3}){3}) - - \[(?P<timestamp>\d+/[A-Za-z]+/\d+:\d+:\d+:\d+ \+\d+)\] "(?P<method>[^"]*) (?P<path>(?:/[^\s"\x27]*|[A-Za-z]:[^\s"\x27]*)) HTTP/1\.1" (?P<status>\d{3}) (?P<number>-?\d+(?:\.\d+)?) "(?P<url>[^"]*)" "(?P<user_agent>[^"]*)"')
''' - note [regex] the message tail diverges across lines and could not be split into stable fields — the trailing per-token literal group(s) are positional word-slices of that unstructured message, not stable fields
- note the pattern contains a single quote, which would close a VRL r'…' regex literal — rewrote each as the RE2 hex escape \x27 (same match semantics) so the argument stays a valid regex literal (parse_regex requires a regex literal, not a string)
Loki
# promtail pipeline for "nginx" (generated by LogForge)
# Add these stages under a scrape_config in your promtail config:
# scrape_configs:
# - job_name: nginx
# pipeline_stages:
# (the stages below are indented to sit under pipeline_stages)
pipeline_stages:
- regex:
expression: '^(?P<ip1>\d{1,3}(?:\.\d{1,3}){3}) - - \[(?P<timestamp>\d+/[A-Za-z]+/\d+:\d+:\d+:\d+ \+\d+)\] "(?P<method>[^"]*) (?P<path>(?:/[^\s"'']*|[A-Za-z]:[^\s"'']*)) HTTP/1\.1" (?P<status>\d{3}) (?P<number>-?\d+(?:\.\d+)?) "(?P<url>[^"]*)" "(?P<user_agent>[^"]*)"$'
- labels:
method:
status:
- note regex: the message tail diverges across lines and could not be split into stable fields — the trailing per-token literal group(s) are positional word-slices of that unstructured message, not stable fields
- note promoted low-cardinality field(s) to Loki labels: method, status
- note left in the extracted map (NOT promoted to labels — high cardinality would explode Loki streams): ip1, timestamp, path, number, url, user_agent
syslog-ng
parser p_nginx {
regexp-parser(
prefix(".nginx.")
patterns("(?<ip1>\\d{1,3}(?:\\.\\d{1,3}){3}) - - \\[(?<timestamp>\\d+/[A-Za-z]+/\\d+:\\d+:\\d+:\\d+ \\+\\d+)\\] \"(?<method>[^\"]*) (?<path>(?:/[^\\s\"']*|[A-Za-z]:[^\\s\"']*)) HTTP/1\\.1\" (?<status>\\d{3}) (?<number>-?\\d+(?:\\.\\d+)?) \"(?<url>[^\"]*)\" \"(?<user_agent>[^\"]*)\"")
);
}; - note regex: the message tail diverges across lines and could not be split into stable fields — the trailing per-token literal group(s) are positional word-slices of that unstructured message, not stable fields
- note captured fields are stored as name-value pairs under the prefix ".nginx." (e.g. a group (?<srcip>…) becomes ".nginx.srcip")
FAQ
- What is the difference between the nginx main, combined, and common log formats?
- combined (nginx's built-in default) is the Common Log Format plus two trailing quoted fields, the Referer and User-Agent. The bare 'common' format stops after the response size. nginx also ships a predefined format literally named 'combined'; 'main' is just a conventional name people give their own custom log_format and carries whatever fields they defined — always check the log_format directive rather than assuming.
- Why does my nginx timestamp fail to parse as ISO 8601?
- Because it is not ISO 8601. nginx writes the local time as 03/Jul/2026:14:22:15 +0300 — day/abbreviated-month/year, a colon before the time, and a numeric UTC offset. Parse it with a %d/%b/%Y:%H:%M:%S %z strptime pattern (Grok's HTTPDATE handles it), and remember the month is a locale-sensitive English abbreviation.
- How do I split the nginx request field into method, path, and protocol?
- The $request field is logged as a single quoted string like "GET /api/health HTTP/1.1". Capture the whole quoted value first, then split it on spaces into method, request URI, and HTTP version. Doing it as one capture avoids miscounting fields when the URI itself contains encoded spaces or the request line is malformed.
- Can the same regex parse both nginx and Apache access logs?
- For the combined format, usually yes — nginx combined and Apache's combined layout are identical field-for-field. The differences that bite are custom log_format lines, Apache's optional %v (vhost) or response-time fields, and whichever module added extra columns. Always validate the pattern against a real sample from each server rather than trusting that 'combined means combined'.
Try it on your own Nginx access lines
Paste a few real lines, review the detected fields, and copy whichever format your stack needs. Free, no account, nothing uploaded.
Open this sample in LogForge →