Advanced Configuration¶

Most test cases run successfully with Load Tester's automatic configuration: ASM handles dynamic fields, cookies work automatically, DNS resolves normally. This guide covers the rare scenarios where you need manual control over low-level HTTP behavior, network configuration, or browser simulation.

You probably don't need any of this unless you encounter one of these specific problems:

JavaScript sets cookies that Load Tester can't capture automatically during recording
Application expects browser-specific cookie values (like BROWSERSUPPORT=yes)
Internal hostnames don't resolve or need to point to test servers instead of production
Proxy server required for network access during recording or replay
Load balancer routes by source IP and requires each virtual user to have a unique IP address
Captcha blocks automated testing and needs workarounds for performance testing

Before diving in, verify that ASM and the standard configuration wizards can't solve your problem. These techniques are more complex and require careful testing.

JavaScript Cookies¶

Problem: Some applications set cookies using JavaScript instead of standard HTTP Set-Cookie headers. During recording, Load Tester captures the JavaScript code, but virtual users don't run JavaScript; they replay HTTP transactions. If the cookie value is required for subsequent requests, replay fails with authentication or session errors.

When You Need This¶

You'll know JavaScript cookies are the problem if:

Recording succeeds, but replay fails with 401/403 errors or session errors
Inspecting recorded transactions shows JavaScript setting a cookie: document.cookie = "session=abc123"
HTTP headers during recording don't show a Set-Cookie header for the required cookie
The application depends on client-side JavaScript to generate or modify cookie values

Common scenarios:

Single-page applications (SPAs) that manage session state in JavaScript
Analytics/tracking cookies set by JavaScript tag managers
Security tokens generated client-side and stored in cookies
Browser fingerprinting cookies set via JavaScript

Why Load Tester Doesn't Run JavaScript¶

Performance constraint: Virtual users must be lightweight. Running a full JavaScript engine (Chrome's V8) for every virtual user would consume massive CPU and memory, limiting scalability to perhaps 10-50 users per machine instead of 500-1000+.

HTTP-level simulation: Load Tester replays the HTTP transactions your browser sent, not the browser itself. This works because web servers only see HTTP requests; they don't know (or care) whether those requests came from a real browser or a load testing tool. JavaScript runs in the browser to generate HTTP requests, but once recorded, you can replay the HTTP without re-executing the JavaScript.

The trade-off: This design maximizes scalability but requires manual configuration when JavaScript performs actions that affect HTTP headers, like setting cookies.

The workflow has three steps:

Locate the cookie value in an HTTP response (it's usually embedded somewhere, even if JavaScript extracts it)
Configure an extractor to capture the value from the response
Configure a processor to set the cookie before the next request that needs it

The cookie value usually appears somewhere in an HTTP response, even if JavaScript extracts it. Check these locations:

Where to look (in order of likelihood):

Hidden form fields: <input type="hidden" name="token" value="abc123">
JavaScript variable assignments: var sessionToken = "abc123";
JSON responses: {"session": "abc123", "expires": 3600}
Embedded in HTML comments: 
URL query parameters: Redirect to /dashboard?session=abc123

How to find it:

Run a replay and let it fail (to generate Headers View data)
Open Headers View for the failing transaction
Click "View Request Headers" to see what cookie Load Tester tried to send
Note the cookie name (e.g., sessionToken) and the value that's missing or wrong
Search backward through previous responses in Headers View for that value
When you find it, note the surrounding text (you'll use this for the extractor)

Example: If the cookie is sessionToken=abc123, search for abc123 in previous responses. You might find:

<script>
  var sessionToken = "abc123";
  document.cookie = "sessionToken=" + sessionToken + "; path=/";
</script>

The value abc123 is right there in the HTML; you just need to extract it.

Step 2: Configure an Extractor¶

Extractors capture values from HTTP responses and store them in variables for later use. You'll create a boundary extractor (easiest) or regex extractor (more flexible) depending on the surrounding text.

To configure an extractor:

Open Actors View: Navigate to the transaction where the cookie value appears
Select the Extractors tab (bottom panel)
Click "Add Extractor" (toolbar button)
Configure the extractor:

Field	Value	Purpose
Name	Descriptive name (e.g., `sessionToken`)	You'll reference this name in the processor
Type	Boundary or Regex	Boundary is easier; Regex handles complex patterns
Start Boundary	Text before the value (e.g., `var sessionToken = "`)	Extractor finds this text first
End Boundary	Text after the value (e.g., `";`)	Extractor stops capturing here
Variable Name	`sessionToken`	Name to store the extracted value

Example boundary extractor for var sessionToken = "abc123";:

Start Boundary: var sessionToken = "
End Boundary: ";
Variable Name: sessionToken

Example regex extractor for <input type="hidden" name="csrf" value="xyz789">:

Regex Pattern: name="csrf"\s+value="([^"]+)"
Capture Group: 1 (the value inside parentheses)
Variable Name: csrfToken
Click OK to save the extractor
Run a replay to verify the extractor captures the value (check Replay View → Variables)

Processors modify HTTP requests before they're sent. You'll create a cookie processor that sets the cookie value using the variable captured by the extractor.

To configure a processor:

Open Actors View: Navigate to the transaction that sends the cookie (usually the next transaction after the extractor)
Select the Processors tab (bottom panel)
Click "Add Processor" (toolbar button)
Select "Cookie Processor"
Configure the processor:

Field	Value	Purpose
Cookie Name	Name the server expects (e.g., `sessionToken`)	Must match what the application expects
Cookie Value	`${sessionToken}`	References the variable from the extractor
Domain	Usually leave blank (auto-detected)	Specifies which domain receives the cookie
Path	Usually `/` (applies to all URLs)	Restricts cookie to specific paths

Example processor to set sessionToken cookie:

Cookie Name: sessionToken
Cookie Value: ${sessionToken} (uses the variable from the extractor)
Domain: (leave blank)
Path: /
Click OK to save the processor
Run a replay to verify:
Transaction succeeds (green in Replay View)
Headers View shows the cookie in the request headers
No 401/403/session errors

Scenario: Application sets a session token via JavaScript: document.cookie = "session=" + token;

Step 1: Locate the value in the response:

<script>
  var token = "abc123def456";
  document.cookie = "session=" + token + "; path=/; secure";
</script>

Step 2: Configure extractor (Actors View → Extractors tab):

Name: Session Token Extractor
Type: Boundary
Start Boundary: var token = "
End Boundary: ";
Variable Name: sessionToken

Step 3: Configure processor (Actors View → Processors tab, on the NEXT transaction):

Type: Cookie Processor
Cookie Name: session
Cookie Value: ${sessionToken}
Path: /

Result: Extractor captures abc123def456 from the response, processor sets Cookie: session=abc123def456 on subsequent requests.

Extractor Captures Wrong Value¶

Symptom: Variable contains unexpected text or nothing at all.

Likely causes:

Boundaries are too broad and capture extra text
Boundaries don't account for whitespace (spaces, tabs, newlines)
Response format changed between recording and replay

Solution:

Add more specific boundaries: Include more surrounding text to narrow the match
Use Regex instead of Boundary: Regex handles whitespace and variations better
View the actual response in Headers View to verify the expected text exists

Symptom: Headers View shows the cookie in the request, but the server rejects it (401/403 error).

Likely causes:

Cookie domain/path is wrong and the browser (or Load Tester) doesn't send it
Cookie requires Secure flag but replay isn't using HTTPS
Cookie requires HttpOnly flag but processor doesn't set it
Cookie value is encoded (URL-encoded, Base64) and processor sends the raw value

Solution:

Check domain/path: Leave domain blank (auto-detect) and use path / unless you know the exact requirements
Verify HTTPS: If the application requires Secure cookies, ensure your test case uses https:// URLs
Add encoding: If the value needs URL encoding, use a Variable Modifier processor first
Inspect Headers View: Compare the cookie Load Tester sends vs. what the browser sent during recording

Ask the AI to Configure JavaScript Cookie Extraction

If you're struggling to locate the cookie value or configure extractors/processors:

My replay fails with session errors. I think the application sets a cookie
via JavaScript. Can you help me find where the cookie value appears in the
response and configure an extractor and processor to handle it?

The AI can:

Search Headers View to locate the cookie value in HTTP responses
Identify the best extraction strategy (boundary vs. regex)
Generate extractor configuration with appropriate boundaries
Configure the processor to set the cookie on the correct transaction
Verify the configuration by analyzing replay results
Troubleshoot extractor/processor issues

Beyond extractors/processors: If your application requires browser-specific cookie values that can't be extracted from responses, you'll need the cookies.cfg file. This is rare; most cookie handling is automatic or solved with extractors/processors.

When You Need cookies.cfg¶

You'll know you need cookies.cfg if:

Application checks a cookie value to determine browser type (e.g., BROWSERSUPPORT=yes vs. BROWSERSUPPORT=no)
Cookie value must be set by the client with no server-provided value to extract
You need to override a cookie value that the server sets (unusual, but sometimes required for testing edge cases)
Different virtual users need different cookie values to simulate browser diversity

Example scenario: Legacy enterprise application checks BROWSERSUPPORT cookie to decide whether to send modern JavaScript or fallback HTML. During recording, your browser sets BROWSERSUPPORT=yes, but Load Tester doesn't automatically set this browser-specific cookie, so replay receives the fallback HTML and fails.

Configuration File Format¶

The cookies.cfg file uses a simple text format to define cookie override rules. Each rule specifies the cookie name, when to apply the rule, and what value to use.

File location: Create cookies.cfg in Load Tester's custom configuration directory:

Windows: C:\Users\<username>\WebPerformance7\config\cookies.cfg
macOS/Linux: ~/WebPerformance7/config/cookies.cfg

See Configuration Files Reference for the exact path on your system.

File format: Plain text, one rule per cookie, rules are numbered sequentially (cookie1, cookie2, etc.):

cookie1.name=COOKIENAME
cookie1.instance=1
cookie1.setFromConstant=value

Or with dataset:

cookie2.name=COOKIENAME
cookie2.instance=1
cookie2.setFromDataset=dataset-name
cookie2.setFromField=column-name

Configuration Parameters¶

Parameter	Required	Description	Example Values
`cookieN.name`	Yes	Cookie name as it appears in HTTP headers	`BROWSERSUPPORT`, `sessionid`, `tracking`
`cookieN.instance`	Yes	Which occurrence of the cookie to override (1 = first time it appears)	`1`, `2`, `3`
`cookieN.setFromConstant`	Conditional	Fixed value to use for all virtual users (mutually exclusive with `setFromDataset`)	`yes`, `supported`, `v1.2.3`
`cookieN.setFromDataset`	Conditional	Dataset name containing cookie values (requires `setFromField`)	`browser-types`, `session-ids`
`cookieN.setFromField`	Conditional	Dataset column name containing cookie values (requires `setFromDataset`)	`browserSupport`, `token`

Numbering rule: Each cookie rule must use a unique number (cookie1, cookie2, cookie3, etc.). If you skip a number, Load Tester ignores all rules after the gap.

Instance rule: If a cookie appears multiple times in a test case (e.g., server renews session cookies), use instance=1 to override the first occurrence, instance=2 for the second, etc. Most scenarios use instance=1 because you want the override to apply from the first occurrence onward.

Scenario: Application expects BROWSERSUPPORT=yes to enable modern features.

cookies.cfg:

cookie1.name=BROWSERSUPPORT
cookie1.instance=1
cookie1.setFromConstant=yes

What this does:

Whenever the test case sends a cookie named BROWSERSUPPORT, Load Tester replaces the value with yes
Applies starting from the first occurrence (instance=1)
All virtual users send the same value

Example 2: Browser Diversity Using Dataset¶

Scenario: Simulate a mix of browsers by varying the USER_AGENT_TYPE cookie. You have a dataset with different browser identifiers.

Dataset (browser-types dataset):

browserType
chrome
firefox
safari
edge

cookies.cfg:

cookie1.name=USER_AGENT_TYPE
cookie1.instance=1
cookie1.setFromDataset=browser-types
cookie1.setFromField=browserType

What this does:

Each virtual user gets a different USER_AGENT_TYPE value from the dataset
Simulates browser diversity during load testing
Virtual user 1 sends USER_AGENT_TYPE=chrome, virtual user 2 sends USER_AGENT_TYPE=firefox, etc.

See Datasets & Data-Driven Testing for details on creating datasets.

Scenario: Override both BROWSERSUPPORT and TRACKING_CONSENT cookies.

cookies.cfg:

cookie1.name=BROWSERSUPPORT
cookie1.instance=1
cookie1.setFromConstant=yes

cookie2.name=TRACKING_CONSENT
cookie2.instance=1
cookie2.setFromConstant=accepted

What this does:

Sets BROWSERSUPPORT=yes starting from the first occurrence
Sets TRACKING_CONSENT=accepted starting from the first occurrence
Both overrides apply to all virtual users

Applying Configuration Changes¶

After editing cookies.cfg:

Save the file (plain text, no formatting)
Restart Load Tester (changes only take effect on startup)
Run a replay to verify the cookies are set correctly
Check Headers View to confirm cookie values in HTTP requests

Do NOT attempt to reload the configuration file while Load Tester is running. The file is read once at startup.

Ask the AI to Generate cookies.cfg Configuration

If you're unsure about the cookie name, instance number, or syntax:

I need to override the BROWSERSUPPORT cookie to always send "yes". Can you
show me the exact cookies.cfg configuration and where to put the file?

The AI can:

Generate the exact cookies.cfg syntax for your scenario
Determine the correct instance number by analyzing your test case
Create datasets if you need cookie values to vary per virtual user
Verify the file location and restart procedure
Troubleshoot issues if cookies aren't being overridden

Hostname Resolution¶

Problem: Internal hostnames don't resolve via DNS, or you need to redirect production hostnames to test servers during load testing without modifying your system's /etc/hosts file (which only affects the controller, not remote engines).

When You Need Custom DNS Overrides¶

You'll know you need hostname resolution configuration if:

Test environment uses internal hostnames (e.g., app.internal.corp) that don't resolve publicly
Production load test must target staging servers (e.g., www.example.com → 10.1.1.5 instead of the live production IP)
Load balancer requires specific IP addresses that differ from public DNS
Remote engines can't resolve hostnames correctly (modifying /etc/hosts on every engine is impractical)

Common scenarios:

Testing pre-production environments with internal DNS
Bypassing CDNs to test origin servers directly
Routing traffic to specific data center IPs for geographic load testing
Working around DNS propagation delays during infrastructure changes

Why Use hosts.txt Instead of System Hosts File¶

System hosts file (/etc/hosts on Linux/macOS, C:\Windows\System32\drivers\etc\hosts on Windows):

❌ Only affects the local machine: you must edit every remote engine's hosts file manually
❌ Requires admin/root privileges to modify
❌ Conflicts with other applications using the same hostnames

Load Tester's hosts.txt:

✅ Automatically distributed to remote engines: configure once, applies everywhere
✅ No admin privileges required (stored in Load Tester's workspace)
✅ Test-specific: doesn't interfere with other applications

hosts.txt File Format¶

The format is identical to the standard /etc/hosts file format. Each line maps an IP address to a hostname (with optional aliases).

File location: Create hosts.txt in Load Tester's custom configuration directory:

Windows: C:\Users\<username>\WebPerformance7\config\hosts.txt
macOS/Linux: ~/WebPerformance7/config/hosts.txt

See Configuration Files Reference for the exact path.

File format: Plain text, one entry per line:

IPAddress     Hostname     [Aliases]

Whitespace: Separate the IP address and hostname with one or more spaces or tabs.

Comments: Lines starting with # are ignored.

Example 1: Single Hostname Override¶

Scenario: Redirect www.example.com to a test server at 10.1.1.5.

hosts.txt:

# Redirect production hostname to test server
10.1.1.5     www.example.com

What this does:

All HTTP requests to www.example.com resolve to 10.1.1.5 instead of the public DNS value
Both controller and remote engines use this override

Example 2: Multiple IPs for Load Balancing¶

Scenario: Round-robin between two backend servers (10.1.1.1 and 10.1.1.2) for app.internal.corp.

hosts.txt (multi-line format):

10.1.1.1     app.internal.corp
10.1.1.2     app.internal.corp

Or (compact format with comma-separated IPs):

10.1.1.1, 10.1.1.2=app.internal.corp

What this does:

Load Tester alternates between the two IP addresses when resolving app.internal.corp
Simulates client-side round-robin load balancing (not true DNS round-robin, which would require server-side configuration)

Example 3: Complete hosts.txt File¶

Scenario: Pre-production environment with multiple internal hostnames.

hosts.txt:

# This is an example hosts.txt file for Load Tester
# Format: IPAddress     Hostname     [Aliases]

# Web servers
10.1.1.5     www.staging.corp     web01
10.1.1.6     www.staging.corp     web02

# API server
10.1.2.10    api.staging.corp

# Database (for monitoring tools, not HTTP)
10.1.3.20    db.staging.corp

What this does:

www.staging.corp resolves to both 10.1.1.5 and 10.1.1.6 (alternating)
api.staging.corp resolves to 10.1.2.10
db.staging.corp resolves to 10.1.3.20
Aliases (web01, web02) are optional but can be used in URLs

Resolution Order¶

When Load Tester resolves a hostname, it checks in this order:

Load Tester's hosts.txt (this file)
System hosts file (/etc/hosts or Windows equivalent)
DNS query (standard network DNS)

If the hostname appears in hosts.txt, Load Tester uses that IP address and skips steps 2 and 3. This means your custom configuration overrides both the system hosts file and DNS.

Applying Configuration Changes¶

After editing hosts.txt:

Save the file (plain text, no formatting)
Restart Load Tester (changes only take effect on startup)
Run a replay to verify hostnames resolve correctly
Check Headers View to see the actual IP address Load Tester connected to

Verifying the override worked:

Open Headers View for any transaction
Look at the Request Line (first line): GET /path HTTP/1.1
Look at the Host header: Host: www.example.com
Look at the TCP connection info (if visible): Should show the IP from hosts.txt, not the public DNS IP

Ask the AI to Generate hosts.txt Configuration

If you're unsure about IP addresses, hostnames, or syntax:

I need to redirect www.example.com to a test server at 10.1.1.5 for load
testing. Can you show me the exact hosts.txt configuration and where to
put the file?

The AI can:

Generate the exact hosts.txt syntax for your scenario
Explain whether you need multi-IP round-robin or single IP override
Verify the file location and restart procedure
Troubleshoot DNS resolution issues during replay
Explain the interaction between hosts.txt, system hosts, and DNS

Proxy Settings¶

Problem: Your network requires HTTP traffic to route through a proxy server, but the default proxy auto-detection fails or you need to use a different proxy for load testing than for regular browsing.

When You Need Proxy Configuration¶

You'll know you need proxy settings if:

Recording fails with "connection refused" or "host not found" errors despite working in your regular browser
IT department requires all HTTP traffic to route through a corporate proxy
Test environment uses a different proxy than production environment
Load Tester auto-detected the wrong proxy during initial setup

Common scenarios:

Corporate networks with mandatory proxy servers for security/logging
Isolated test environments with dedicated proxy infrastructure
Geographic testing through region-specific proxies
Bypassing proxies for internal URLs while using proxies for external URLs

Proxy Auto-Detection¶

On first recording, the Recording Configuration Wizard attempts to auto-detect your system's proxy settings (from browser configuration, Windows registry, macOS network preferences, or environment variables).

If auto-detection succeeds, you don't need to configure anything. Load Tester uses the detected proxy automatically.

If auto-detection fails:

Recording fails with connection errors
Test cases record successfully but contain no transactions (proxy blocked them)
Load Tester doesn't route traffic through the expected proxy

In these cases, you'll manually configure proxy settings in the Preferences dialog.

Configuring Proxy Settings¶

To configure or modify proxy settings:

Navigate to: Tools → Preferences (or Window → Preferences on macOS)
Expand: Load Tester in the tree
Select: Proxy Settings

You'll see the Proxy Settings preference page with a list of configured proxies and an asterisk (*) marking the default proxy.

Adding a New Proxy¶

To add a new proxy configuration:

Click: Add button (right side of the proxy list)
Enter proxy details in the lower-right panel:

Field	Description	Example
Name	Descriptive name for this proxy	`Corporate Proxy`, `Test Lab Proxy`
Proxy Host	Hostname or IP address of the proxy server	`proxy.corp.com`, `10.0.0.50`
Proxy Port	Port number the proxy listens on (usually 8080, 3128, or 80)	`8080`, `3128`
Username	(Optional) Authentication username if proxy requires credentials	`jdoe`
Password	(Optional) Authentication password if proxy requires credentials	`P@ssw0rd`

Click: Apply to save the new proxy
Make it the default: Select the proxy in the list and click Make Default (adds an asterisk *)
Click: OK to close Preferences

The default proxy (marked with *) is automatically configured in the browser when you start a recording.

Modifying an Existing Proxy¶

To change an existing proxy:

Select the proxy in the list (upper-left panel)
Edit the details in the lower-right panel (host, port, credentials)
Click: Apply to save changes
Click: OK to close Preferences

To restore original settings: Before clicking Apply, click Restore Defaults to undo your changes.

Deleting a Proxy¶

To remove a proxy configuration:

Select the proxy in the list
Click: Delete button
Confirm deletion

Important: You cannot delete the default proxy. If you want to remove the current default, first make a different proxy the default (or select No Proxy), then delete the unwanted proxy.

Disabling Proxy (Direct Connection)¶

To bypass all proxies (use direct connection):

Select: No Proxy in the proxy list
Click: Make Default
Click: Apply and OK

This is useful for:

Testing on networks that don't require a proxy
Troubleshooting whether proxy configuration is causing issues
Comparing performance with and without proxy overhead

Copying an Existing Proxy¶

To create a new proxy based on an existing one:

Select the proxy you want to copy
Click: Copy button
Edit the copied proxy (it appears in the list as "Copy of ...")
Rename it and modify settings as needed
Click: Apply to save

This is useful when you need multiple proxy configurations that differ slightly (e.g., different credentials, different ports, different hostnames).

Re-Detecting Proxy Settings¶

To force Load Tester to re-detect your system's proxy (useful if network configuration changed):

Click: Auto Detect button
Load Tester scans system settings (browser config, registry, network preferences)
If a proxy is found, it's added to the list or updated
Click: Apply and OK

Proxy Authentication¶

If your proxy server requires authentication, enter your credentials in the Authentication Credentials section (lower-right panel):

Username: Your proxy authentication username
Password: Your proxy authentication password

If your proxy does NOT require authentication, leave these fields blank.

Security note: Credentials are stored in Load Tester's workspace (encrypted on macOS, obfuscated on Windows). If multiple users share the same workspace, they'll share the same proxy credentials. For sensitive environments, consider using individual workspaces or environment-specific proxy configurations.

Troubleshooting Proxy Configuration¶

Recording Fails with "Connection Refused"¶

Symptom: Recording starts, browser opens, but no transactions appear in the recording, or all transactions fail with connection errors.

Likely causes:

Wrong proxy host or port
Proxy requires authentication but credentials are missing
Proxy is down or unreachable from your network
Firewall blocks Load Tester from connecting to the proxy

Solution:

Verify proxy settings with your IT department (correct host, port, credentials)
Test the proxy from a command line: curl -x http://proxy.corp.com:8080 http://www.example.com
Check firewall rules: Ensure Load Tester is allowed to connect to the proxy
Try "No Proxy" temporarily to verify the problem is proxy-related

Browser Uses Wrong Proxy During Recording¶

Symptom: Recording succeeds, but the browser routes traffic through a different proxy than expected (or bypasses the proxy entirely).

Likely causes:

Wrong proxy is marked as default (doesn't have the * asterisk)
Browser cached old proxy settings and didn't apply the new configuration
Browser extension overrides proxy settings (e.g., proxy switcher extension)

Solution:

Verify default proxy: Check that the correct proxy has the * asterisk in the list
Restart the recording: Close the browser and start a new recording session
Disable browser extensions: If the browser has proxy-related extensions, disable them during recording
Check Preferences: Ensure you clicked Apply and OK after changing proxy settings

Ask the AI to Configure Proxy Settings

If you're unsure about proxy configuration or troubleshooting connection errors:

My recording fails with connection errors. I think I need to configure a
proxy server, but I'm not sure what settings to use. Can you help me figure
out the correct proxy configuration?

The AI can:

Guide you through finding your system's current proxy settings
Generate the exact Preferences configuration based on your proxy details
Troubleshoot connection errors and verify proxy settings
Explain authentication requirements and credential storage
Compare proxy vs. no-proxy performance to isolate issues

IP Aliasing (Multiple IP Addresses)¶

Problem: Your application routes traffic based on client IP address (e.g., load balancer uses source IP for session affinity), and all virtual users originating from a single IP address causes incorrect behavior or unrealistic load distribution.

When You Need IP Aliasing¶

This is a rare configuration. Most applications don't care about client IP addresses. Do not set up IP aliasing unless you are certain it's required.

You'll know you need IP aliasing if:

Load balancer routes by source IP and all virtual users hit the same backend server (instead of distributing across servers)
Application limits concurrent sessions per IP and virtual users get blocked
Geographic routing uses IP address and you need to simulate users from different locations
Security rules rate-limit by IP and single-IP testing triggers those limits

Consult with your network administrator before proceeding. Incorrect IP configuration can render your computer inoperable.

How IP Aliasing Works¶

By default, all virtual users originate from the same IP address (the controller's primary network adapter). This works fine for 99% of applications because web servers don't care about source IP; they only care about HTTP headers, cookies, and session state.

With IP aliasing enabled, you configure your operating system to create virtual network interfaces, each with its own IP address. During a load test, Load Tester assigns each virtual user a different IP address from the pool of available interfaces. If you have more virtual users than IP addresses, multiple users share IPs (round-robin).

Example:

Without IP aliasing: 100 virtual users all originate from 10.0.0.100
With IP aliasing (5 IPs configured): 100 virtual users split across 10.0.0.100, 10.0.0.101, 10.0.0.102, 10.0.0.103, 10.0.0.104 (20 users per IP)

Two-Step Configuration Process¶

IP aliasing requires TWO separate configurations:

Operating System configuration (create virtual network interfaces at the OS level)
Load Tester configuration (tell Load Tester which IP addresses to use)

You must complete BOTH steps for IP aliasing to work.

Step 1: Operating System Configuration¶

This step is dangerous. Incorrect network configuration can break your network connectivity entirely. Work with your network administrator to obtain valid IP addresses and subnet masks before proceeding.

IP address requirements:

Must be on the same subnet as your primary network adapter (same network, different host)
Must be UNUSED by other machines on the network (duplicate IPs cause conflicts)
Must be STATIC (not DHCP-assigned); IP aliasing doesn't work with DHCP
Consult your network administrator to reserve a block of IPs for load testing

Typical configuration: Reserve 5-10 IP addresses on your test network (e.g., if your primary IP is 10.1.1.100, reserve 10.1.1.101 - 10.1.1.110).

Windows Configuration¶

Step 1: Open Network Connections:

Right-click: My Network Places (on the Desktop)
Or: Start → Control Panel → Network and Dial-up Connections

Step 2: Edit Network Adapter Properties:

Right-click your Local Area Connection (NOT VPN, ISDN, or dial-up, as those don't support IP aliasing)
Select: Properties

Step 3: Configure TCP/IP:

Select: Internet Protocol (TCP/IP) from the list
Click: Properties button

Step 4: Verify Static IP Configuration:

Ensure "Use the following IP address" is selected (NOT "Obtain an IP address automatically" via DHCP)
If using DHCP, IP aliasing won't work. You must configure a static IP first (consult your network admin)

Step 5: Open Advanced TCP/IP Settings:

Click: Advanced button

Step 6: Add Virtual IP Addresses:

In the IP addresses list, you'll see your primary IP address
Click: Add button
Enter:
IP address: The virtual IP to add (e.g., 10.1.1.101)
Subnet mask: Usually the same as your primary IP (e.g., 255.255.255.0)
Click: OK to add the IP
Repeat for each additional IP address you want to configure

Step 7: Save and Apply:

Click: OK on all dialogs to save changes
Restart the network adapter (or reboot) to activate the new IPs

Verification:

ipconfig /all

You should see multiple IP addresses listed for your Local Area Connection.

Linux/UNIX Configuration¶

Using ifconfig (temporary, does not survive reboot):

# Add a virtual interface with IP 10.1.1.101
sudo ifconfig eth0:0 10.1.1.101 netmask 255.255.255.0

# Add more virtual interfaces
sudo ifconfig eth0:1 10.1.1.102 netmask 255.255.255.0
sudo ifconfig eth0:2 10.1.1.103 netmask 255.255.255.0

Verification:

ifconfig

You should see eth0:0, eth0:1, eth0:2 interfaces listed.

Permanent configuration (survives reboot):

Red Hat/CentOS/Fedora: Create files /etc/sysconfig/network-scripts/ifcfg-eth0:0, ifcfg-eth0:1, etc.
Debian/Ubuntu: Edit /etc/network/interfaces to add virtual interfaces
Or: Add ifconfig commands to /etc/rc.local startup script

Consult the Linux Network Administrators Guide or your distribution's documentation for permanent configuration details.

Step 2: Load Tester Configuration¶

After configuring virtual IPs at the OS level, you must configure Load Tester to use those IPs during load testing.

Configuring the Local Workstation¶

To configure IP aliasing on the controller:

Navigate to: Window → Preferences → Load Tester → IP Aliasing
You'll see: A list of all IP addresses available on your system (primary + virtual IPs you just configured)

Default behavior: Load Tester uses "Use OS Default", which selects the primary network adapter automatically.

To enable IP aliasing:

Select: "Use Selected Interfaces"
Check the boxes next to the IP addresses you want virtual users to use
Uncheck any IP addresses you want to exclude (e.g., wireless adapters, VPN connections)
Click: Apply and OK

Example:

Your system has 5 IPs: 10.1.1.100 (primary), 10.1.1.101, 10.1.1.102, 10.1.1.103, 10.1.1.104 (virtual)
Check all 5 to allow virtual users to use any of these IPs
Uncheck wireless IP (192.168.1.50) if you don't want virtual users using Wi-Fi

Result: During load testing, each virtual user is assigned one of the selected IPs (round-robin).

Configuring Remote Engines¶

If you use remote engines, you must configure IP aliasing separately for each engine (OS-level configuration happens on each engine machine, Load Tester configuration happens via the Engines View).

To configure IP aliasing for a remote engine:

Perform OS-level configuration on the remote engine machine (follow Windows or Linux steps above)
In Load Tester, open: Engines View
Select the engine you want to configure
Click: Configure IPs button (toolbar)
A dialog appears showing the engine's available IP addresses (Load Tester queries the engine to get this list)
Select: "Use Selected Interfaces"
Check the boxes next to the IPs you want the engine to use
Click: OK

Repeat for each remote engine.

Verification¶

To verify IP aliasing works:

Run a small load test (5-10 virtual users)
Monitor server logs or load balancer logs to see source IP addresses
Expected result: You should see requests coming from multiple IP addresses (not just one)

If all requests still come from a single IP:

Verify OS-level configuration (run ipconfig or ifconfig to confirm virtual IPs exist)
Verify Load Tester configuration (Use Selected Interfaces is selected, not Use OS Default)
Restart Load Tester after changing IP Aliasing preferences

Troubleshooting IP Aliasing¶

Virtual Users Still Use Single IP¶

Symptom: Server logs show all requests coming from the same IP address despite configuring multiple IPs.

Likely causes:

Load Tester not configured to use the virtual IPs (still using "Use OS Default")
Virtual IPs not checked in the IP Aliasing preferences
OS-level configuration failed (virtual IPs don't actually exist at the OS level)

Solution:

Check Preferences: Ensure "Use Selected Interfaces" is selected and the desired IPs are checked
Verify OS config: Run ipconfig (Windows) or ifconfig (Linux) to confirm virtual IPs exist
Restart Load Tester: IP Aliasing preferences only take effect after restart

Network Connectivity Lost After Configuring Virtual IPs¶

Symptom: After adding virtual IPs at the OS level, you lose network connectivity (can't browse the web, ping other machines, etc.).

Likely causes:

Incorrect subnet mask (doesn't match your network)
Duplicate IP address (another machine on the network already uses one of the IPs you configured)
Gateway or DNS settings corrupted during configuration

Solution:

Remove virtual IPs immediately: Reverse the OS-level configuration steps
Verify IP addresses with network admin: Ensure the IPs you're using are valid and unused
Double-check subnet mask: Must match your primary IP's subnet mask
If you can't recover, restore network settings from backup or contact IT support

This is why we told you to consult your network administrator before configuring IP aliasing.

Ask the AI About IP Aliasing Requirements

If you're unsure whether you need IP aliasing or how to configure it:

My load balancer routes traffic based on source IP, and all my virtual users
are hitting the same backend server. Do I need IP aliasing? How do I configure
it safely?

The AI can:

Determine whether your scenario actually requires IP aliasing (most don't)
Explain the risks and prerequisites before you start
Guide you through safe OS-level configuration
Generate the exact commands for your operating system
Configure Load Tester's IP Aliasing preferences
Troubleshoot connectivity issues after configuration
Suggest alternatives (e.g., testing with diverse session cookies instead of IPs)

Captcha Handling¶

Problem: Your application uses CAPTCHA to prevent automated access (by design), but you need to performance-test it anyway.

When Captcha Blocks Load Testing¶

Captcha exists specifically to stop automated tools, including load testing tools. If a load testing tool could easily bypass captcha, so could every spammer on the internet.

You'll know captcha is blocking your test if:

Recording succeeds (you solve the captcha manually during recording)
Replay fails because virtual users can't solve the captcha
Application returns "captcha failed" or similar errors during load testing

Common captcha types:

Image-based: "Type the text you see in the image" (reCAPTCHA v1, traditional captcha)
Checkbox: "I'm not a robot" checkbox (reCAPTCHA v2)
Invisible: Background analysis without user interaction (reCAPTCHA v3, hCaptcha invisible)
Puzzle-based: "Drag the slider to complete the puzzle" (hCaptcha, GeeTest)

Three Options for Load Testing with Captcha¶

None of these options bypass captcha. They all require cooperation from your development or operations team. That's the nature of the problem.

Option 1: Disable Captcha for the Test Environment (Recommended)¶

What: Configure the application to skip captcha validation in the test environment.

Why this is best:

✅ No code changes to the load testing tool required
✅ Realistic load testing (all other application logic runs normally)
✅ No security risk (only affects test environment, not production)
✅ Fastest replay performance (no captcha delay)

How:

Coordinate with development team: Ask them to add a configuration flag to disable captcha in non-production environments
Example: if (environment == "production") { validate_captcha(); }
Deploy to test environment with captcha disabled
Run load test against test environment

Security note: Ensure the captcha-disabled configuration cannot be deployed to production (use environment variables, separate config files, or deployment gates to prevent mistakes).

Option 2: Configure Captcha to Accept Any Value¶

What: Configure the captcha service to accept any input as valid (no actual validation).

Why this works:

✅ Load Tester can replay the recorded captcha response (which will be accepted)
✅ No changes to the test case required
✅ Application logic proceeds normally after "passing" captcha

How:

Coordinate with development team: Ask them to configure the captcha service in "test mode"
reCAPTCHA: Google provides a test site key that always accepts any response
Test site key: 6LeIxAcTAAAAAJcZVRqyHh71UMIEGNQ_MXjiZKhI
Test secret key: 6LeIxAcTAAAAAGG-vFI1TnRWxMZNFuojJ4WifJWe
Replace production keys with test keys in the test environment
Custom captcha: Add a bypass mode that skips validation but logs attempted solutions
Run load test with any captcha value (the recorded value, or a dummy value)

Security note: Test keys must NOT be used in production.

Option 3: Expose Captcha Answer in the HTML (Advanced)¶

What: During load testing, the captcha service embeds the correct answer somewhere in the HTML where Load Tester can extract it.

Why this works:

✅ Simulates the captcha-solving process (extract → submit)
✅ Tests the full application flow including captcha submission

How:

Coordinate with development team: Ask them to add a hidden field or HTML comment containing the captcha answer
Example: <input type="hidden" id="captcha_answer" value="abc123"> or 
Configure an extractor in Load Tester to capture the answer (see JavaScript Cookies section for extractor/processor workflow)
Configure a field modifier to set the captcha field to the extracted value
Run load test

Security note: This HTML-embedded answer must be removed before deploying to production. Use feature flags or environment-specific templates to ensure it only appears in test environments.

Recommended Approach¶

For most teams: Option 1 (disable captcha) is simplest and safest.

If you must test captcha logic: Option 2 (accept any value) tests the captcha submission flow without requiring extractors.

For advanced scenarios: Option 3 (embed answer) simulates realistic captcha-solving behavior, but requires careful coordination to avoid accidentally deploying the answer-embedding code to production.

Ask the AI About Captcha Configuration

If you need help coordinating with your development team or configuring extractors:

My application uses reCAPTCHA and I need to performance-test it. What's the
safest way to configure the test environment so Load Tester can bypass the
captcha without compromising production security?

The AI can:

Recommend the best option based on your captcha type and environment
Generate example configuration for reCAPTCHA test keys
Explain how to configure extractors if you choose Option 3
Provide sample code for development team (feature flags, environment checks)
Verify that your test configuration doesn't affect production
Troubleshoot captcha-related replay failures

Troubleshooting Advanced Configuration¶

Configuration File Changes Don't Take Effect¶

Symptom: You edited cookies.cfg or hosts.txt, but Load Tester still uses the old behavior.

Likely causes:

Load Tester not restarted (configuration files are read at startup only)
Wrong file location (file is in the wrong directory)
File permissions wrong (Load Tester can't read the file)
Syntax errors in file (Load Tester ignores malformed configuration)

Solution:

Restart Load Tester after editing configuration files
Verify file location: Use Tools → Preferences → Load Tester → Configuration Files to see the exact path
Check file permissions: Ensure the file is readable (not locked, not admin-only)
Validate syntax: Check for typos, incorrect numbering (cookie1, cookie2 with no gaps), or malformed entries

Extractors Capture Wrong Value or Nothing¶

Symptom: Extractor variable contains unexpected text, partial text, or is empty.

Likely causes:

Boundaries too broad (capture too much text)
Boundaries too narrow (never match)
Response format changed between recording and replay
Whitespace in boundaries (spaces, tabs, newlines) not accounted for

Solution:

View the actual response in Headers View to verify the expected text exists
Use more specific boundaries: Include more surrounding text to narrow the match
Switch to Regex extractor: Regex handles whitespace variations better
Enable extractor logging: Check diagnostic logs to see what the extractor matched

Remote Engines Don't Use Custom Configuration¶

Symptom: Custom configuration (hosts.txt, IP aliasing) works on the controller but not on remote engines.

Likely causes:

Configuration files not distributed (hosts.txt is local to the controller)
IP aliasing not configured per-engine (each engine needs its own configuration)
Engine version mismatch (older engines may not support some configuration options)

Solution:

hosts.txt IS automatically distributed to engines. Verify the file exists on the controller first
IP aliasing requires per-engine configuration: Use Engines View → Configure IPs for each engine
Verify engine version: Ensure all engines match the controller version
Check engine logs: Remote engine logs may show configuration errors

Ask the AI to Diagnose Configuration Issues

If advanced configuration isn't working as expected:

I configured hosts.txt to redirect www.example.com to 10.1.1.5, but Load Tester
is still connecting to the public IP address. Can you help me figure out why
the configuration isn't being applied?

The AI can:

Verify file location and syntax
Check whether Load Tester was restarted after configuration changes
Analyze Headers View to see actual connection details
Diagnose extractor/processor configuration issues
Explain resolution order (hosts.txt vs. system hosts vs. DNS)
Suggest alternative approaches if the configuration isn't working

Next Steps¶

After configuring advanced settings, verify your test case works correctly:

Running a Replay - Verify all transactions succeed with the new configuration
Debugging Failed Replays - Troubleshoot configuration-related failures

For additional configuration topics:

Application State Management - ASM handles most dynamic fields automatically
Authentication - Configure authentication before worrying about advanced settings
Datasets & Data-Driven Testing - Use datasets for cookie values, browser diversity, etc.

For reference:

Configuration Files Reference - Complete list of configuration file locations and formats
Preferences Reference - All Load Tester preferences explained

Advanced Configuration¶

JavaScript Cookies¶

When You Need This¶

Why Load Tester Doesn't Run JavaScript¶

Solution: Extract Cookie Value and Set It Manually¶

Step 1: Locate the Cookie Value in the Response¶

Step 2: Configure an Extractor¶

Step 3: Configure a Processor to Set the Cookie¶

Complete Example: Session Token Cookie¶

Troubleshooting JavaScript Cookie Configuration¶

Extractor Captures Wrong Value¶

Processor Sets Cookie But It's Ignored¶

Advanced Cookie Configuration (cookies.cfg)¶

When You Need cookies.cfg¶

Configuration File Format¶

Configuration Parameters¶

Example 1: Fixed Browser Support Cookie¶

Example 2: Browser Diversity Using Dataset¶

Example 3: Multiple Cookie Overrides¶

Applying Configuration Changes¶

Hostname Resolution¶

When You Need Custom DNS Overrides¶

Why Use hosts.txt Instead of System Hosts File¶

hosts.txt File Format¶

Example 1: Single Hostname Override¶

Example 2: Multiple IPs for Load Balancing¶

Example 3: Complete hosts.txt File¶

Resolution Order¶

Applying Configuration Changes¶

Proxy Settings¶

When You Need Proxy Configuration¶

Proxy Auto-Detection¶

Configuring Proxy Settings¶

Adding a New Proxy¶

Modifying an Existing Proxy¶

Deleting a Proxy¶

Disabling Proxy (Direct Connection)¶

Copying an Existing Proxy¶

Re-Detecting Proxy Settings¶

Proxy Authentication¶

Troubleshooting Proxy Configuration¶

Recording Fails with "Connection Refused"¶

Browser Uses Wrong Proxy During Recording¶

IP Aliasing (Multiple IP Addresses)¶

When You Need IP Aliasing¶

How IP Aliasing Works¶

Two-Step Configuration Process¶

Step 1: Operating System Configuration¶

Windows Configuration¶

Linux/UNIX Configuration¶

Step 2: Load Tester Configuration¶

Configuring the Local Workstation¶

Configuring Remote Engines¶

Verification¶

Troubleshooting IP Aliasing¶

Virtual Users Still Use Single IP¶

Network Connectivity Lost After Configuring Virtual IPs¶

Captcha Handling¶

When Captcha Blocks Load Testing¶

Three Options for Load Testing with Captcha¶

Option 1: Disable Captcha for the Test Environment (Recommended)¶

Option 2: Configure Captcha to Accept Any Value¶

Option 3: Expose Captcha Answer in the HTML (Advanced)¶

Recommended Approach¶

Troubleshooting Advanced Configuration¶

Configuration File Changes Don't Take Effect¶

Extractors Capture Wrong Value or Nothing¶

Remote Engines Don't Use Custom Configuration¶

Next Steps¶