projectdiscovery/nuclei · error

'%s' is not a valid extract type

Error message

'%s' is not a valid extract type

What it means

Returned by setProtocolType in pkg/templates/types/types.go when toProtocolType cannot map the given string to a known ProtocolType. It fires both when parsing protocol lists from template YAML (ProtocolTypes.UnmarshalYAML) and when parsing CLI flags wired to ProtocolTypes.Set (e.g. -protocols). The message text 'not a valid extract type' is a copy-paste artifact; the real meaning is 'not a valid protocol type name'. Valid names come from protocolMappings: dns, file, http, offline-http, headless, tcp, workflow, ssl, websocket, whois, code, javascript.

Source

Thrown at pkg/templates/types/types.go:198

	return json.Marshal(stringProtocols)
}

func (protocolTypes ProtocolTypes) String() string {
	var stringTypes []string
	for _, t := range protocolTypes {
		protocolMapping := t.String()
		if protocolMapping != "" {
			stringTypes = append(stringTypes, protocolMapping)
		}

	}
	return strings.Join(stringTypes, ", ")
}

func setProtocolType(protocolTypes *ProtocolTypes, value string) error {
	computedType, err := toProtocolType(value)
	if err != nil {
		return fmt.Errorf("'%s' is not a valid extract type", value)
	}
	*protocolTypes = append(*protocolTypes, computedType)
	return nil
}

View on GitHub (pinned to 265b3a3dec)

Solutions

1. Correct the protocol name to one of: dns, file, http, offline-http, headless, tcp, workflow, ssl, websocket, whois, code, javascript — note the network protocol is called 'tcp', not 'network'
2. Run `nuclei -h` or call types.SupportedProtocolsStrings() to see the exact accepted strings for your nuclei version
3. If the value comes from user input or config, validate it against types.SupportedProtocolsStrings() before passing it to ProtocolTypes.Set or loading the template
4. Check for stray whitespace or YAML list syntax issues (e.g. 'http, dns,' leaving an empty element) that produce an empty/invalid token

Example fix

# before
nuclei -u target.com -protocols network,ssl
# error: 'network' is not a valid extract type

# after
nuclei -u target.com -protocols tcp,ssl

import types "github.com/projectdiscovery/nuclei/v3/pkg/templates/types"

func validateProtocolNames(names []string) error {
    supported := map[string]bool{}
    for _, s := range types.SupportedProtocolsStrings() {
        supported[s] = true
    }
    for _, n := range names {
        if !supported[n] {
            return fmt.Errorf("unsupported protocol %q (note: network protocol is registered as %q)", n, "tcp")
        }
    }
    return nil
}

func isValidProtocolName(name string) bool {
    for _, s := range types.SupportedProtocolsStrings() {
        if s == name { return true }
    }
    return false
}

err := protocolTypes.Set(userValue)
if err != nil {
    // message is misleading ('extract type') — treat as invalid protocol name
    return fmt.Errorf("bad protocol in config %q: %w (valid: %v)", userValue, err, types.SupportedProtocolsStrings())
}

When it happens

Trigger: Passing any string not in protocolMappings: 'network' (the network protocol is registered as 'tcp'), 'js' (registered as 'javascript'), 'offlinehttp'/'offline_http' (registered as 'offline-http'), or typos like 'htp'. Concretely: `-protocols network`, `-type tcp,htt`, or a template YAML field typed as ProtocolTypes containing an unknown entry — each reaches setProtocolType, toProtocolType fails, and the error is returned with the offending value in the message.

Common situations: Using -protocols/-exclude-protocols on the CLI with the long name 'network' instead of 'tcp'; template authors writing 'js' instead of 'javascript'; custom tooling built on the nuclei SDK feeding user-supplied protocol names straight into ProtocolTypes.Set; copy-pasted YAML with case or spelling drift after nuclei renames a protocol.

Related errors

• validation failed for these fields
• Invalid severity: %s
• Invalid extractor type: %s
• Invalid matcher type: %s
• unresolved variables found: %s

AI-assisted analysis of projectdiscovery/nuclei@265b3a3dec (2026-08-15). Data as JSON: /api/errors/b637c79dc19cd923. Report an issue: GitHub.