Site Connection Issue
Hello support,
We are experiencing issues with when using the API to connect to specific sites. When attempting to connect to site A from IP address Z we receive a “host is down” type error and when we connect to the same site A from ip address Y, we are able to connect. We are not sure what the particular cause of this is as we are able to successfully connect to other sites from ip address Z. Are there any rate limit rules that flag ip addresses that we may be experiencing?
What other issues could potentially be causing this and how can we avoid this in the future?
Thank you
-
Hello support,
Were you able to find an answer my above question?
Thank you
0 -
Hey Elan,
I am not affiliated with Network Optix, but I'd like to help you. Could you share more information on how you're actually trying to connect? Through relay host, or SITEA-IP:port?
Are you getting any HTTP error codes?
You can attach screenshots too.
0 -
-
Hi Elan,
Thanks for your question here.
The details in your post (with references like X/Y/Z and A/B/C) make it a bit hard to follow. Would you mind sharing more specifics , specifically which API, which site, and the exact URL involved? That'll help us (and others in the community) understand the issue faster.
As Mohammed suggested, a screen recording or screenshots would also go a long way toward getting you a quicker answer.
0 -
Apologies for the ambiguity. We are connecting to the cloud vms using the relay host, so the url looks like <cloud_system_id>.relay.vmsproxy.com/rest/v3/devices.
To answer Mohammed, we are sometimes getting 200 responses and sometimes getting 500 errors with the response: {'error': '6', 'errorId': 'internalServerError', 'errorString': 'Network error on connect to Server {guid}: Connection timed out'}.
We have tried raising the timeout, but we don't think this is the issue as when we change the server from which me make these requests everything works fine. This is why we were wondering if there were any rate limit rules that flag ip addresses that are making the requests coming from a given ip address respond with an error.
Thank you.
0 -
Could you try the same but with location-specific relay host, for example
<cloud_system_id>.relay-us-chi-1-prod-dp.vmsproxy.comIf this also behaves the same, you connection from the server to the cloud relay is intermittent, that what I noticed with few systems I worked with.
1 -
-
Ok, Thank you Mohammed, we will try that. Is there a list of proxy urls that we can use when the standard approach does not work?
0 -
Hi
Hard-coding<cloud_system_id>.relay-us-chi-1-prod-dp.vmsproxy.comisn't going to work reliably here, so we'd recommend against that approach.When a site connects to the cloud, there are actually three relay points listening on the relay requests. These typically sit behind the same CDN, but the CDN can route you to a different relay or region at any time.
Since that routing is dynamic, hard-coding a specific relay hostname isn't a stable solution (and it's not something we support).
Instead, each relay-through request will return a redirect URL in the response's
Locationheader. The right approach is to follow that redirect and send your authentication along with it, rather than assuming a fixed endpoint.Hope this helps.
For the HTTP 500, it is probably the mediaserver connectivity at local should be checked and investigated in usual, if you can reproduce the issue, we are happy to check it.
Thanks!
0 -
Hi Ichiro,
The customer showed us that the server is live while the requests we issue are returning a 500 error. We do not hard-code the URL, we do route it dynamically using the response's Location as you described and this process works just fine for very many servers for a large portion of the time.
One solution we have found is to change the IP address from which we connect and that seems to address the issue. Is there some form of rate limiting or other technology that we should be aware of?
Thank you
0 -
Hello support,
Have you been able to find an answer to my previous question?
Thank you,
Elan
0 -
Hi
To help us get to the bottom of this, could you walk us through the exact steps to reproduce the issue on your end? We've tried to replicate it in our test environment but haven't been able to see the same behavior yet, so a step-by-step procedure would really help.
Also, you mentioned:
"One solution we have found is to change the IP address from which we connect and that seems to address the issue. Is there some form of rate limiting or other technology that we should be aware of?"
Could you expand on this a bit? Specifically, what rate limit you're referring to ?
Did you notice specific error messages, response codes, or any pattern (e.g., number of requests per minute) that pointed you toward rate limiting as the cause?
0 -
Hi Ichiro,
Our general process is straightforward and works across many accounts. We authenticate using the ‘cdb/oauth2/token’ endpoint and then use that token to continue making requests to the API across endpoints such as ‘rest/v3/devices'.
Nothing specific indicated to us that there was a rate limit, but we do notice that if we switch the server that makes the requests (i.e., the ip-address), suddenly the same code works. Therefore, we assume it has something to do with rate-limiting/black-listing our IP and we were wondering what the potential reason for having our ip address flagged and blocked from making requests to the API was. Do you know what scenario could cause this?
0 -
Hi Elan,
When you say
if we switch the server that makes the requests (i.e., the ip-address),
Which IP address you were referring to?The IP of the cloud relay server or the mediaserver IP address?
0
Please sign in to leave a comment.
Comments
12 comments