我去 Google 查了一下， Python 的线程实现有一些奇怪的行为。
比如，主线程如果 block 在 thread.join()上，是不能捕获消息的（可能和全局解释器锁有关）。

我拿 StackOverflow 上的一个不通的示例代码作了些修改，使 CTRL+C 可以成功工作了（这里在主线程中调用 signal.pause()等待 SIGINT ， join()不行）：

import signal, sys, threading, time

THREADS = []

def handler(signal, frame):
global THREADS
print "Ctrl-C.... Exiting"
for t in THREADS:
t.alive = False
sys.exit(0)

class thread(threading.Thread):
def __init__(self):
self.alive = True
threading.Thread.__init__(self)


def run(self):
n = 0
while self.alive:
n = n + 1
print("round %s" %n)
time.sleep(1)
pass

def main():
global THREADS
t = thread()
t.start()
THREADS.append(t)
signal.pause()
for t in THREADS:
t.join()

if __name__ == '__main__':
signal.signal(signal.SIGINT, handler)
main()


一些资料：
http://stackoverflow.com/questions/1635080/terminate-a-multi-thread-python-program
http://stackoverflow.com/questions/19652446/python-program-with-thread-cant-catch-ctrlc
http://stackoverflow.com/questions/631441/interruptible-thread-join-in-python

我不是专门的 Python 程序员，查了一下， Python 里面的信号默认只会被主线程捕获，猜测应该是对子线程设置了 signal mask 。
楼主或许可以尝试这两个方法：
1. 主线程中处理 SIG_INT ，强制终止子线程。
2. 或者在子线程中设置一个 bool 变量，每次循环前检查 bool 变量的值决定继续执行或退出。

你直接用 CTRL+C 终止的话， wsclient.recv()应该会触发中断异常才对。

测试过了，线路和 vultr 一样，实际效果还不如后者。
专门开了一台机器，晚上 8:50 北京联通 200M 普通家宽测试：

1. 路由追踪：
Host Loss% Snt Last Avg Best Wrst StDev
1. *.*.*.* 0.0% 51 1.5 1.7 0.9 3.6 0.3
2. 221.223.80.1 0.0% 50 154.1 50.8 5.1 202.7 39.5
3. 61.148.174.53 0.0% 50 7.2 6.4 3.6 12.5 1.7
4. 61.51.114.121 0.0% 50 6.9 7.5 3.1 71.6 9.3
5. 61.148.153.49 0.0% 50 6.1 8.0 3.3 81.3 10.6
6. 202.96.12.65 0.0% 50 4.8 7.1 4.0 33.8 4.0
7. 219.158.112.170 0.0% 50 9.9 10.1 5.9 74.8 9.7
8. 219.158.97.230 0.0% 50 9.9 10.3 4.8 119.7 15.8
9. 219.158.34.154 12.0% 50 209.6 215.2 197.6 291.8 19.7
10. ae-5.r23.osakjp02.jp.bb.gin.ntt.net 10.0% 50 210.2 215.9 192.9 235.4 8.3
ae-5.r22.osakjp02.jp.bb.gin.ntt.net
11. ae-5.r31.tokyjp05.jp.bb.gin.ntt.net 6.0% 50 218.3 225.3 211.8 252.7 6.4
ae-5.r30.tokyjp05.jp.bb.gin.ntt.net
12. ae-2.r02.tokyjp05.jp.bb.gin.ntt.net 6.0% 50 220.9 220.3 202.5 375.3 23.9
ae-3.r02.tokyjp05.jp.bb.gin.ntt.net
13. 192.80.16.6 2.0% 50 222.2 219.2 205.1 319.4 15.3
14. 139.162.64.6 0.0% 50 227.0 224.3 211.8 263.6 7.7
15. *.members.linode.com 6.1% 50 228.8 223.4 211.6 231.1 5.2

2. 反向路由追踪：
Host Loss% Snt Last Avg Best Wrst StDev
1. 139.162.*.* 0.0% 56 0.8 0.6 0.5 0.9 0.0
2. 139.162.64.7 0.0% 56 0.8 0.9 0.6 1.1 0.0
3. 192.80.16.5 0.0% 56 1.4 1.3 1.2 1.7 0.0
4. ae-3.r31.tokyjp05.jp.bb.gin.ntt.net 5.4% 56 1.0 1.9 0.9 8.4 1.8
5. ae-10.r23.osakjp02.jp.bb.gin.ntt.net 5.4% 56 8.3 15.7 8.2 76.1 19.4
6. ae-9.r21.osakjp02.jp.bb.gin.ntt.net 0.0% 56 8.2 8.2 8.1 8.4 0.0
7. p64-0.cnc-g.osakjp02.jp.bb.gin.ntt.net 5.5% 56 236.0 228.3 188.5 237.8 9.8
8. 219.158.4.54 3.6% 55 219.1 221.0 174.4 230.2 10.8
9. 219.158.112.177 7.3% 55 216.3 221.3 168.4 229.3 11.2
10. 124.65.194.18 3.6% 55 214.4 220.7 163.4 228.8 11.0
11. 61.148.1.165 5.5% 55 222.8 228.6 166.3 238.4 11.1
12. 61.148.174.186 3.6% 55 215.7 219.8 158.5 242.0 11.4
13. 221.223.*.* 1.8% 55 220.0 220.5 158.7 228.6 10.9

3. HTTP 下载只有 30-50KB/s 。

结论：还不如 Linode Fremont 。 Fremont 高峰还能跑个 1-2MB/s ，而且几乎不丢包。

@herolulu 去掉你的路由，用光猫直连电脑，关闭电脑上的防火墙再试一次。
如果还不行就是电信局端给封了。

要检测这种故障，先减少其他无关设备的影响才是。两层 nat+dmz 太复杂了。直接光猫改桥接，用网线直连电脑拨号试一试就知道是不是运营商的问题了。

我读了一下这则新闻，居然还觉得他们分析得头头是道，然并卵

没有 Google 服务框架的悲哀。

这不是基础吗？换我面试我也会问。

没读懂，我猜是防流量穿透的

@redsonic 北京联通这边 icmp tcp udp 全部不通，用 nc 测试 80 、 443 端口全部超时，看起来像是回程进了路由黑洞

iPhone 5s （逃）

外企工作的路过，五险一金和个税一分不少交，连过年发的几百块红包都被扣 20%的税。

树莓派性能太弱了，而且百兆网卡和 USB2.0 都是瓶颈。搞 nas 还是应该上 x86 服务器。

建议楼主看一下 Unix 的 fork 系统调用。
简单来说：操作系统这一层就是这么设计的，操作系统才不关心你的 Python 文件，那是 Python 解释器关心的东西，不在一个层次上

@imeilige 我当年的国行 HTC one M7 就是双卡双待双通的。。。

没有人知道为什么，楼主提供的信息太少。
上网出现问题：
找 ISP 沟通解决❌
上 V2EX 发帖✔

@jiuzhe http://shcainfo.miitbeian.gov.cn/publish/query/indexFirst.action 查不到

/go/flamewar