Something went wrong. Please check your internet connection and try again

Hello everyone,

we have two unattended licensed servers in the company, one is connected without any issues to both the orchestrator and the internet, but the second one, which has just been set up, cannot connect to the internet.

I can connect to the orchestrator and it shows that it is connected with a license, but when I try to download a package and install it in the Assistant, it tells me that it cannot connect to the internet.

Hi @victorsantanadav

  • Check the machine’s network/proxy settings if the working server uses a proxy to reach the internet, the new one likely needs the same proxy configured in Windows (and in UiPath Studio/Assistant if it uses system proxy settings).
  • Whitelist the required UiPath domains (e.g. .UiPath.com, cloud.uipath.com, your Orchestrator URL, and the package feed URLs) on the firewall/proxy for this machine Orchestrator connectivity uses different endpoints than package download, so one can work while the other doesn’t.
  • Confirm the Robot/Assistant is set to download packages from the correct feed source (Orchestrator vs official UiPath feed) in Studio’s package settings if it’s pointed to the public feed, it needs direct internet access to nuget.org/UiPath feed servers.
  • Test connectivity manually from that machine (browser or Test-NetConnection) to the package feed URL; if it fails there too, it’s a network/firewall issue outside UiPath, not a licensing/Orchestrator problem.

Hi @victorsantanadav

what Manikandan said covers proxy and feed pretty well, one more thing i would check on a freshly configured server, the system clock

if the date/time on the second server is off even by a few minutes, the TLS handshake to the package feeds fails silently and throws that generic “check your connection” error, while the Orchestrator connection can keep working because it validates differently. Its very common on freshly spun up VMs that dont have automatic time sync configured

also check if TLS 1.2 is enabled at the Windows level on that server, some Windows Server builds default to TLS 1.0/1.1 wich breaks outgoing https calls to the feeds specifically without touching other connections

if you fix the clock and TLS and it still fails, then its more likely the proxy/firewall side Manikandan already mentioned

hope it helps as well :slight_smile: