sorry to anyone that failed to get a free tunnel over the past few hours, a phishing complaint that likely came in before I added this warning triggered a domain suspension. The free tunnels are working again on a different domain name while I sort out the suspension.

for non-browser requests, and on browsers after accepting the warning, tunnels should work exactly as before, but if you have any problems please let me know and I will get them fixed.

this is to deal with a high volume of phishing complaints I have been receiving against free domains. It is less that 5 users behind all the phishing domains reported, and so they will soon move on I will revert to passing traffic thru without this warning.

hello 👋️ i have put up a phishing warning on the free domains. this is a temporary measure, it will be removed in the near future, and while it is live you can simply accept the warning and enjoy your tunnel as before.

RT @beganovichhh: Want to quickly share the local site/app with your friend? Put this snippet in your .bashrc/.zshrc and you should be good….

RT @benedictbartsch: I just discovered and it is amazing. For the @PaddleHQ integration I’m building for FeatureCa….

RT @andrewlocknet: Blogged: Using SSH and @localhost_run to test @github webhooks locally #dotnet #aspnetcore.

Thank you so much to Weimin Wang, the author of pywebio and an awesome person, for choosing to integrate our two products, it's so awesome to see being used in awesome products like pywebio 🙏️.

if you haven't seen the pywebio project definitely check it out at , and if you already know it then check out for the lhr integration 💪️.

👋️ hello peeps. i'm super excited to tell you there's a new version of pywebio out. Not only is pywebio a very fast way to get an interactive site up and running 🚀️ also starting with version 1.3 it is integrated with 🙌️.

the bug didn't quite die, my keep-at-n system shipped the old code last night while i was asleep so there was again some down time, sorry :( code is properly committed and we're back up now, I'm awake and drinking coffee, i'll keep a very close eye on it thru the day.

and thank you all for bearing with me thru this🙏️.

Over the next few weeks I will do a longer write up on this outage and describe how I run on AWS ECS, how I debugged this low-ish level TCP bug on ECS (hint: i didn't 😉️), and future plans for the system, so keep an eye on my twitter feed for that.

once I found this bug the fix was easy, if the data is "short" i now check if the connection is closed before i try to read for more, and this now seems to be a happy place again.

After some time I hit the system limit for open sockets, my kernel stopped accepting new connections, and my loadbalancer finally terminated that instance to start the cycle over.

This exercised a bug in this piece of code that meant i was rapidly looping a read around these closed connections expecting more data that would never arrive. the socket got stuck in CLOSE_WAIT, the cpu started spinning and as more "short" connections arrived sockets leaked.

it's been very well treated code, but something changed today and this previously happy place became very unhappy, this initial data periodically came thru "short", a partial header and then the connection closed.

i read a few bytes into new connections to pull out proxy header data. this part of my system is fairly stable because those first few bytes come from my loadbalancers, which keep things like port scans and short data probes away from this code.

what a day! mistakes have been made and lessons have been learned, and I am sorry that I took you all on that journey with me but i've finally found and fixed the root cause (i think). So what was it?.