> This page is for Applications Protection.

> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.humansecurity.com/llms.txt.

# Troubleshooting

## Viewing Logs

To troubleshoot the iRule added to the F5 BIG-IP, SSH into the BIG-IP machine, enter the bash shell, and check the LTM logs:

```bash
tail -f /var/log/ltm
```

## Enable Debug Logging

For detailed troubleshooting, you can enable debug mode which provides additional logging information about the enforcer's decision-making process.

### Enable Debug Mode

```bash
modify /ltm data-group internal pxconfig records modify { debug { data 1 } }
```

### Disable Debug Mode

```bash
modify /ltm data-group internal pxconfig records modify { debug { data 0 } }
```

> **Important**
>
> Debug mode generates significant log output and can impact performance. Only enable it temporarily for troubleshooting, and remember to disable it in production environments.

## Test Block Flow on Monitoring Mode

When the enforcer is in Monitor Mode (`module_mode = 1`), you can still test the blocking flow without affecting real traffic. This is useful for validating that blocking works correctly before switching to full blocking mode.

### Configuration

Set the bypass monitor header in the `pxconfig` data group:

```bash
modify /ltm data-group internal pxconfig records modify { bypass_monitor_header { data x-px-block } }
```

### Usage

Once configured, you can test blocking by including the header in your request:

1. Set the header `x-px-block: 1` on your request
2. Trigger a detection (e.g., use a User-Agent header with the value `PhantomJS/1.0`)
3. The enforcer will bypass Monitor Mode and apply full Block Mode for this request

**Conditions for bypass:**

* The `bypass_monitor_header` must be configured
* The header must be present in the request with a value of `1`
* The request must trigger a block response (high risk score)

If any condition is missing, the enforcer will stay in Monitor Mode.

To explicitly stay in Monitor Mode even when the header is present, set the header value to `0`:

* `x-px-block: 0` - Stay in Monitor Mode

> **Note**
>
> This feature is per-request. It does not change the global module mode setting.

## Common Issues

### No Activity Data in HUMAN Console

If you're not seeing activity data in the HUMAN Console:

1. Verify that the Syslog configuration is complete (see [Installation](/applications/bigipf5-installation#configuring-activities-report))
2. Check that your F5 IP address has been authorized with HUMAN backends
3. Verify the `px_syslog_pool` is healthy and can reach `px-fst-syslog.perimeterx.net`
4. Ensure the `CLIENT_ACCEPTED` rule is uncommented in the px iRule

### Risk API Timeouts

If you're seeing high `s2s_timeout` rates:

1. Check that `px_backend_pool` is healthy
2. Verify the virtual server `px_backend_<APP_ID>_vip` is configured correctly
3. Consider increasing `risk_timeout` if network latency is high:

```bash
modify /ltm data-group internal pxconfig records modify { risk_timeout { data 3000 } }
```

### Module Not Processing Requests

If the enforcer doesn't seem to be processing requests:

1. Verify `enable_module` is set to `1`
2. Check if `enable_module_header_name` is configured and if so, ensure the header is present
3. Verify the px iRule is attached to your virtual server
4. Check the `excluded_extensions` pattern isn't matching your requests

### iRule Size Exceeded Error

If you see this error when uploading the px iRule:

```
01070712:3: Max string size exceeded during update of attribute:definition type:rule max:65520 received:67873
```

The `px.tcl` file exceeds F5's 65,520 byte limit for iRules.

**Solution:** Minify the iRule before uploading:

```bash
sed '/^[[:space:]]*#/d' px.tcl | cat -s > px-minified.tcl
```

This command removes comment lines and collapses blank lines. The minified iRule is functionally identical to the original.

Use `px-minified.tcl` instead of `px.tcl` when creating the iRule.