ERROR: SonarCloud server [] can not be reached


We’ve been creating a new droplet in DigitalOcean in order to be used as a Github runner for our development activities. After running the tests, there is the SonarCloud Scan step. On the other similar droplets that we have (with similar configuration), the connection and analysis work as expected. However, for this specific droplet, we have connection errors:

INFO: Scanner configuration file: /opt/sonar-scanner/conf/
INFO: Project root configuration file: /github/workspace/
INFO: SonarScanner
INFO: Java 17.0.8 Alpine (64-bit)
INFO: Linux 6.1.0-9-amd64 amd64
INFO: User cache: /opt/sonar-scanner/.sonar/cache
ERROR: SonarCloud server [] can not be reached
INFO: ------------------------------------------------------------------------
INFO: ------------------------------------------------------------------------
INFO: Total time: 5.531s
ERROR: Error during SonarScanner execution
org.sonarsource.scanner.api.internal.ScannerException: Unable to execute SonarScanner analysis
at org.sonarsource.scanner.api.internal.IsolatedLauncherFactory.lambda$createLauncher$0(
INFO: Final Memory: 5M/48M
at java.base/
at org.sonarsource.scanner.api.internal.IsolatedLauncherFactory.createLauncher(
at org.sonarsource.scanner.api.internal.IsolatedLauncherFactory.createLauncher(
at org.sonarsource.scanner.api.EmbeddedScanner.doStart(
at org.sonarsource.scanner.api.EmbeddedScanner.start(
at org.sonarsource.scanner.cli.Main.execute(

From the same machine, I can ping with no problems.

I’m suspecting that the droplet IP is somehow blocked by sonarcloud, but can this be confirmed? Or there might be other reasons for this connection problem.

Any help would be appreciated,
Cristian N

Hi Cristian,

Welcome to the community!

Is this consistently replicable or was that, perhaps, a glitch?

Is that the full stacktrace? And if not, can you provide the whole thing?

…would that not be the same IP?


Hi Ann,

It was replicable every run, so definately not a glitch. However, a traceroute from that IP shown that at the 3rd or 4th hop, something is happening (and comparing with a traceroute from the other machines that were working, it was clearly a difference). Unfortunately I don’t have that trace at hand, and I decided to give it a go with a renewed IP, which worked.

A lot of IPs allocated by DigitalOcean end up in all kind of blacklists, so probably this one was heavily involved and somehow, a filtering happened along the way.

Unless SonarCloud is doing this sort of filtering itself?!

Anyway, happy that I’ve fixed the situation, more worrisome that this can repeat any time with the future (github runners) deployments.

1 Like

Hello Cristian,

I’m happy that you managed to solve the situation.
I can confirm that we have some security protections in front of SonarCloud and some IPs can be blocked if they are considered as a threat.
Renewing your public IP is a good thing when it is applicable. If not, don’t hesitate to share your public IP with us so that we can investigate and understand what is blocking the connection.

I wish you a good day

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.