Interactsh is not always triggered when scanning large lists

[reacan]

Hello everyone,

I am scanning URL lists with "nuclei -l list.txt -iserver my.interactsh.srv -itoken thetoken" and I noticed that the message "[INF] Using Interactsh Server: my.interactsh.srv" doesn't always appear, checked the access logs on my server and really there are scans that do not trigger Interactsh.

Tried to find the threshold, at first seemed like it is around 55 URLs, then again it came down to about 30 URLs. Inconsistent.

When scanning single URLs the Interactsh server is always triggered.

Tried adding the flags "for the most thorough scan" -severity info,low,medium,high,critical -rl 150 -bs 50 -c 50 -timeout 10 -retries 3, still the same result:

[INF] Found 29 URL from httpx
[INF] Templates clustered: 2275 (Reduced 79402 Requests)
[INF] Using Interactsh Server: my.interactsh.srv

[INF] Running httpx on input host
[INF] Found 67 URL from httpx
[INF] Templates clustered: 2275 (Reduced 197432 Requests)
And no Interactsh here :(

Does anyone know anything about this? How do you scan massive lists and make sure that the scan is thorough with Interactsh being used?

Many thanks in advance for your insights!

[PhinehasNarh]

Yeah, I've hit this exact thing and it's almost always a timing/eviction issue rather than your templates being wrong. The tell is that single targets always fire but big lists go flaky.

Two defaults bite you on large lists:

• -interactions-cooldown-period is only 5s. That's the extra window Nuclei keeps polling the interactsh server after the scan engine finishes. Out-of-band callbacks (especially DNS, and anything where the app calls home a few seconds later) often land after that 5s window has already closed, so Nuclei has stopped polling and never correlates them. On a single URL the callback is basically instant so you never notice; across 60 URLs the slow ones just get dropped.
• -interactions-eviction defaults to 60s and -interactions-cache-size to 5000. On a long, noisy run the cache can rotate out the correlation entry for an early target before its delayed callback comes back.

So 30 vs 55 isn't a magic number, it's just whichever interactions happen to be slow on that run.

What's worked for me, widen the polling windows so late callbacks still get caught:

nuclei -l list.txt \
  -iserver my.interactsh.srv -itoken thetoken \
  -interactions-cooldown-period 60 \
  -interactions-poll-duration 5 \
  -interactions-eviction 120 \
  -interactions-cache-size 20000 \
  -rl 150 -bs 50 -c 50

Start with just -interactions-cooldown-period 60, that's the one that fixes it for most people. The cache-size/eviction bumps matter more the bigger the list gets.

Couple of things worth ruling out too:

• If you're self-hosting interactsh, check it isn't rate-limiting or dropping correlation IDs under load, and that it's reachable over both DNS and HTTP from the targets.
• -rl 150 is pretty hot. If a target or upstream WAF throttles you, the app may never get far enough to fire the callback, so run a slower control scan to confirm it's timing and not requests getting eaten.

To prove it's the cooldown, run the same list with -interactions-cooldown-period 120 and see if your hit count stabilises across runs.

[reacan]

Thank you very much for sharing your experience and insights, highly appreciated. I will definitely give this a go!