Remote Access for Axeda Agent Assets through ThingWorx > Troubleshooting Remote Access > General > Symptom: The ThingWorx Remote Access Client (RAC) fails to connect to the platform when initiating a session
Symptom: The ThingWorx Remote Access Client (RAC) fails to connect to the platform when initiating a session
Here is an example of the RAC initializing a remote session with ThingWorx Platform:
As shown above, the RAC initially displays a "Connecting to Thingworx" message on the platform icon. When, after a period of time, the RAC cannot connect to the platform, the message, "Unable to connect to Thingworx", appears, as shown here:
The next three sections provide three possible causes and the actions that users and administrators should take to try to resolve the issue.
Cause: Connection to Platform Interrupted 
If the connection to the ThingWorx Platform was interrupted, an administrator should ensure that the user has connectivity to ThingWorx Platform.
Cause: Invalid nonce key 
As of v.1.2.0 of the RAE and v.1.1.0 of the RAC, a temporary nonce key is used for authentication with a ThingWorx Platform instead of an application key. If the nonce key sent to ThingWorx Platform is invalid, the following actions should be taken:
User or Administrator — When the RAC is launched through a mashup that implements the Remote Access Client Linker Widget, a temporary nonce key is provisioned for use by the client when it is launched. If some delay causes the launch of the client to take longer than 15 seconds, it is possible the nonce key will no longer be valid. In this case, it might be possible to simply re-try starting a session. If you are using an earlier version of the RAC, that is prior to v.1.1.0, then it uses an application key, which is valid for 15 seconds but continues to exist for 30 seconds.
Cause: Incorrect Proxy Settings 
If the settings for the proxy server are not correct, users can check that the proxy settings entered in the UI of the RAC are correct. From the ellipsis menu, select Proxy Settings, as shown here:
In the proxy settings dialog, ensure that the proxy host and port are configured to point to a valid proxy server instance:
Administrators should confirm that the config.json file where the client is being launched is configured to use a valid proxy server/port. Proxy servers requiring authentication are not currently supported. The format of the file should look like this:

{
"proxy": {
"host": "proxy.com"
"port": 1234
}
}
The file is typically located at ~/.config/tw-ra-client/config.json in Linux and %USER_HOME%\AppData\Roaming\tw-ra-client\config.json on Windows On OS X, it is located at ~/Library/Application Support/tw-ra-client.
Cause: Platform Not an HTTPS Instance 
Users should check the ThingWorx Platform they are using has an SSL/TLS-enabled endpoint configured and use that endpoint to initiate the session instead.
Administrators can enable insecure access for the client in the config.json file. Along with proxy configuration, a flag can be specified in the configuration file to allow insecure access. The format of the file would be:

{
"secure": false,
"proxy": {...}
}
* 
The insecure parameter in the configuration file enables or disables TLS for all connections made by the Remote Access Client, so it is not possible to connect to an insecure platform but a secure Remote Access Server, for example to a GAS.
The default behavior of the Remote Access Client (if the secure flag is not specified) is equivalent to the secure property being set to true.
Was this helpful?