Imagine you are hacking and you come across 4 parameters that all seem to resolve external URLs. You try google.com but it does not work. You get no feedback.
There are two things you can do in this situation. You can either give up or try to insert the URL of your own out-of-band server into the parameters. Settings up these servers can be cumbersome and this is why burp suite offers us a helping hand so and does a lot of the work for us.
Out of band servers are network services that listen for requests and have the ability to report back to the attacker, either via the access log monitoring or a more active system. Portswigger has created an out-of-band server for use that they call the collaborator. In the free version, you have to use the public server which is not always reliable. In this case, I recommend using any of the free private alternatives such as:
every collaborator or out of band server will need a unique domain name to make a callback to. This will make it easier to recognize which parameter caused the callback if you use a different server for every parameter/target. It provides an HTTP/HTTPS service and uses a valid, CA-signed, wildcard TLS certificate for its domain name. It also provides an SMTP/SMTPS service.
Whenever an external makes a callback to one of these services we can test further for things like blind RFI or blind SSRF. You will sometimes notice DNS callbacks but no HTTPs callback to accompany it. This is harder to exploit and usually is caused by egress filtering. (filtering outgoing traffic)
This can help you to detect blind XSS, Blind SSRF, RFI, non-time based blind SQLi and possibly other issues that require out of band resource loading.