Discussions

Issue 1. Due to the Toronto node being down earlier on, I "soft disabled" my endpoint. Now that I have turned it back on, I am encountering errors:

• The status page at https://controld.com/status shows the correct resolver ID.
• The same resolver ID is linked to only one profile.
• The profile has been redirecting some services, such as Vimeo.
• The profile also has some custom rules in place.
• There are no custom rules in the profile that interfere with the service redirection rules.
• https://controld.com/status shows that DNS and Proxy are functioning correctly, and all parameters appear fine.
• However, when visiting Vimeo, it is not being redirected. Clicking on https://vimeo.com/cdn-cgi/trace still shows my real home IP (note: /cdn-cgi/trace is a Cloudflare CDN endpoint used by Vimeo that returns data about the browser and the connecting IP).
• Checking the activity log at https://controld.com/dashboard/activity-log shows that vimeo.com is being "bypassed," but it is supposed to be redirected.
• I verified that I am using ControlD with the correct resolver ID linked to the profile where redirections are set, by checking https://ipleak.net/ and https://controld.com/status.

The issue affects all services and custom rules in the profile, not just Vimeo (Vimeo was just an example). The bug seems to occur only on the endpoint that I "soft disabled" and re-enabled. The same profile is used on other endpoints, but those do not have this issue. I have ruled out browser cache and DNS, as the problem can also be reproduced using dig commands.

I made no changes to the profile or endpoint settings other than "soft disabling" my endpoint and turning it back on. The TTL is set to 60 seconds. I cleared the browser cache, restarted, and waited for an hour to ensure the TTL expired, but the issue persists. Any idea why this might be happening? Could it be a bug related to turning the endpoint on again after being "soft disabled"?

Issue 2. As for a separate incident (different endpoint, different profile from the issue above):

On Oct 16 and Oct 17 EDT, another endpoint of mine linked to a different profile (which has absolutely no redirection rules) had an issue. The endpoint has only one profile and there is no multiple chained profiles. When visiting Google.com, it resulted in an SSL error and by checking with nslookup the domain google.com resolved to a Control-D IP address, meaning it was redirected when it was not supposed to be. However, the CD dashboard log at that exact time showed it was bypassed, but in reality, it was incorrectly redirected.

---

One thing in common between issue 1 and issue 2 is that both of these endpoints were once "soft disabled" and then turned back on. All other endpoints, even when using the same profiles, work as expected.

However, for the endpoints that had been disabled and then re-enabled, the actual behavior does not match the configured rules, nor does it align with the CD activity log.