[GH-ISSUE #77] Memory hog / crash after receiving a real https request #68

Closed
opened 2026-02-26 12:33:53 +03:00 by kerem · 1 comment
Owner

Originally created by @yatli on GitHub (Nov 24, 2019).
Original GitHub issue: https://github.com/cbeuw/Cloak/issues/77

I'm running cloak as a shadowsocks plugin.
A few ck-server instances are spawned on startup, each taking a gentle amount of memory. However after a while, all these ck-server instances blow up eating hundreds of megs, and then die.

A screenshot of dying instances:
image

Here are a few warnings at the end of the SS log:

● shadowsocks-libev.service - Shadowsocks-libev Default Server Service
   Loaded: loaded (/lib/systemd/system/shadowsocks-libev.service; enabled; vendor preset: enabled)
   Active: inactive (dead) since Sun 2019-11-24 17:25:19 UTC; 59s ago
     Docs: man:shadowsocks-libev(8)
  Process: 2254 ExecStart=/usr/bin/ss-server -c $CONFFILE $DAEMON_ARGS (code=exited, status=0/SUCCESS)
 Main PID: 2254 (code=exited, status=0/SUCCESS)

Nov 24 17:25:05 __server_name__ ss-server[2254]: time="2019-11-24T17:25:05Z" level=warning msg="unreconised protocol" UID= encryptionMethod=0 proxyMethod= remoteAddr="127.0.0.1:41544" sessionId=0
Nov 24 17:25:05 __server_name__ ss-server[2254]: time="2019-11-24T17:25:05Z" level=warning msg="unreconised protocol" UID= encryptionMethod=0 proxyMethod= remoteAddr="127.0.0.1:41546" sessionId=0
Nov 24 17:25:05 __server_name__ ss-server[2254]: time="2019-11-24T17:25:05Z" level=warning msg="unreconised protocol" UID= encryptionMethod=0 proxyMethod= remoteAddr="127.0.0.1:41548" sessionId=0
Nov 24 17:25:05 __server_name__ ss-server[2254]: time="2019-11-24T17:25:05Z" level=warning msg="unreconised protocol" UID= encryptionMethod=0 proxyMethod= remoteAddr="127.0.0.1:41550" sessionId=0
Nov 24 17:25:05 __server_name__ ss-server[2254]: time="2019-11-24T17:25:05Z" level=warning msg="unreconised protocol" UID= encryptionMethod=0 proxyMethod= remoteAddr="127.0.0.1:41552" sessionId=0
Nov 24 17:25:05 __server_name__ ss-server[2254]: time="2019-11-24T17:25:05Z" level=warning msg="unreconised protocol" UID= encryptionMethod=0 proxyMethod= remoteAddr="127.0.0.1:41554" sessionId=0
Nov 24 17:25:05 __server_name__ ss-server[2254]: time="2019-11-24T17:25:05Z" level=warning msg="unreconised protocol" UID= encryptionMethod=0 proxyMethod= remoteAddr="127.0.0.1:41556" sessionId=0
Nov 24 17:25:05 __server_name__ ss-server[2254]: time="2019-11-24T17:25:05Z" level=warning msg="unreconised protocol" UID= encryptionMethod=0 proxyMethod= remoteAddr="127.0.0.1:41558" sessionId=0
Nov 24 17:25:05 __server_name__ ss-server[2254]: time="2019-11-24T17:25:05Z" level=warning msg="unreconised protocol" UID= encryptionMethod=0 proxyMethod= remoteAddr="127.0.0.1:41560" sessionId=0
Nov 24 17:25:05 __server_name__ ss-server[2254]: time="2019-11-24T17:25:05Z" level=warning msg="unreconised protocol" UID= encryptionMethod=0 proxyMethod= remoteAddr="127.0.0.1:41562" sessionId=0

This typically means some scanner has been trying to reach the port thinking it's https, but ck-server doesn't like those requests.

To repro, open up a browser, navigate to https://__server__.com and see how the ck-server instances crash.

Originally created by @yatli on GitHub (Nov 24, 2019). Original GitHub issue: https://github.com/cbeuw/Cloak/issues/77 I'm running cloak as a shadowsocks plugin. A few ck-server instances are spawned on startup, each taking a gentle amount of memory. However after a while, all these ck-server instances blow up eating hundreds of megs, and then die. A screenshot of dying instances: ![image](https://user-images.githubusercontent.com/20684720/69498390-8f8e6500-0f22-11ea-8465-8c8165ca1831.png) Here are a few warnings at the end of the SS log: ``` ● shadowsocks-libev.service - Shadowsocks-libev Default Server Service Loaded: loaded (/lib/systemd/system/shadowsocks-libev.service; enabled; vendor preset: enabled) Active: inactive (dead) since Sun 2019-11-24 17:25:19 UTC; 59s ago Docs: man:shadowsocks-libev(8) Process: 2254 ExecStart=/usr/bin/ss-server -c $CONFFILE $DAEMON_ARGS (code=exited, status=0/SUCCESS) Main PID: 2254 (code=exited, status=0/SUCCESS) Nov 24 17:25:05 __server_name__ ss-server[2254]: time="2019-11-24T17:25:05Z" level=warning msg="unreconised protocol" UID= encryptionMethod=0 proxyMethod= remoteAddr="127.0.0.1:41544" sessionId=0 Nov 24 17:25:05 __server_name__ ss-server[2254]: time="2019-11-24T17:25:05Z" level=warning msg="unreconised protocol" UID= encryptionMethod=0 proxyMethod= remoteAddr="127.0.0.1:41546" sessionId=0 Nov 24 17:25:05 __server_name__ ss-server[2254]: time="2019-11-24T17:25:05Z" level=warning msg="unreconised protocol" UID= encryptionMethod=0 proxyMethod= remoteAddr="127.0.0.1:41548" sessionId=0 Nov 24 17:25:05 __server_name__ ss-server[2254]: time="2019-11-24T17:25:05Z" level=warning msg="unreconised protocol" UID= encryptionMethod=0 proxyMethod= remoteAddr="127.0.0.1:41550" sessionId=0 Nov 24 17:25:05 __server_name__ ss-server[2254]: time="2019-11-24T17:25:05Z" level=warning msg="unreconised protocol" UID= encryptionMethod=0 proxyMethod= remoteAddr="127.0.0.1:41552" sessionId=0 Nov 24 17:25:05 __server_name__ ss-server[2254]: time="2019-11-24T17:25:05Z" level=warning msg="unreconised protocol" UID= encryptionMethod=0 proxyMethod= remoteAddr="127.0.0.1:41554" sessionId=0 Nov 24 17:25:05 __server_name__ ss-server[2254]: time="2019-11-24T17:25:05Z" level=warning msg="unreconised protocol" UID= encryptionMethod=0 proxyMethod= remoteAddr="127.0.0.1:41556" sessionId=0 Nov 24 17:25:05 __server_name__ ss-server[2254]: time="2019-11-24T17:25:05Z" level=warning msg="unreconised protocol" UID= encryptionMethod=0 proxyMethod= remoteAddr="127.0.0.1:41558" sessionId=0 Nov 24 17:25:05 __server_name__ ss-server[2254]: time="2019-11-24T17:25:05Z" level=warning msg="unreconised protocol" UID= encryptionMethod=0 proxyMethod= remoteAddr="127.0.0.1:41560" sessionId=0 Nov 24 17:25:05 __server_name__ ss-server[2254]: time="2019-11-24T17:25:05Z" level=warning msg="unreconised protocol" UID= encryptionMethod=0 proxyMethod= remoteAddr="127.0.0.1:41562" sessionId=0 ``` This typically means some scanner has been trying to reach the port thinking it's https, but `ck-server` doesn't like those requests. To repro, open up a browser, navigate to `https://__server__.com` and see how the `ck-server` instances crash.
kerem closed this issue 2026-02-26 12:33:53 +03:00
Author
Owner

@yatli commented on GitHub (Nov 24, 2019):

Meh, I did not set up a redir server.

<!-- gh-comment-id:557910907 --> @yatli commented on GitHub (Nov 24, 2019): Meh, I did not set up a redir server.
Sign in to join this conversation.
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#68
No description provided.