[GH-ISSUE #227] feature suggestions (2): more aggressive connection checking when there's activity on listening port + minor unrelated DNS stuff #186

New issue

Open

opened 2026-02-26 12:34:12 +03:00 by kerem · 0 comments

kerem commented

2026-02-26 12:34:12 +03:00

Owner

Originally created by @LindaFerum on GitHub (Aug 1, 2023).
Original GitHub issue: https://github.com/cbeuw/Cloak/issues/227

So, long story short I've got opportunity to give Cloak a ride in a fairly hostile environment in an idiosyncratic setup

It works (I'm posting yay)

Using it in Direct mode (CDN does not work, separate issue created previously

Two little suggestions so far

allow explicitly specifying a dns resolver for Cloak to use instead of system's
Yes I can use iptables to redirect to dnscrypt / other resolver but being able to put it in a config would be nice
Just quality of life thing
a more important matter. In case server IP changes Cloak can spend a while detecting connection broke, much longer than it takes for DNS to reflect the changes

Using aggressive keepalives mitigates that (time between AWS shutdown and re-activation with keepalives set to 10 is between 1 and 2 minutes but with keepalives set to 300 it is 4-7 minutes)

Given that all this time there's activity on Cloak's listening port (openvpn trying to reconnect) , maybe it would be possible to have a feature that allows to initiate aggressive connection restoration when ("activity on listening port" + "no response from upstream for X seconds, with X value separately configurable" ), as distinct from just using keepalives?

Mitigating via keepalives is inferior both due to detection risk and because frankly it eats into battery quite a bit.

Originally created by @LindaFerum on GitHub (Aug 1, 2023). Original GitHub issue: https://github.com/cbeuw/Cloak/issues/227 So, long story short I've got opportunity to give Cloak a ride in a fairly hostile environment in an idiosyncratic setup It works (I'm posting yay) Using it in Direct mode (CDN does not work, separate issue created previously Two little suggestions so far 1) allow explicitly specifying a dns resolver for Cloak to use instead of system's Yes I can use iptables to redirect to dnscrypt / other resolver but being able to put it in a config would be nice Just quality of life thing 2) a more important matter. In case server IP changes Cloak can spend a while detecting connection broke, much longer than it takes for DNS to reflect the changes Using aggressive keepalives mitigates that (time between AWS shutdown and re-activation with keepalives set to 10 is between 1 and 2 minutes but with keepalives set to 300 it is 4-7 minutes) Given that all this time there's activity on Cloak's listening port (openvpn trying to reconnect) , maybe it would be possible to have a feature that allows to initiate aggressive connection restoration when ("activity on listening port" + "no response from upstream for X seconds, with X value separately configurable" ), as distinct from just using keepalives? Mitigating via keepalives is inferior both due to detection risk and because frankly it eats into battery quite a bit.

kerem referenced this issue

2026-02-26 12:34:30 +03:00

[PR #186] [MERGED] Update browser fingerprints #286

No labels

pull-request

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/Cloak#186

No description provided.

Rows
Columns