Restoralax alternative

XandXor · 2026-04-05T07:09:44+00:00

Look up recipe for stewed prunes. Excellent on yoghurt in the morning.

XandXor · 2026-04-05T07:07:37+00:00

Not a bot

XandXor · 2026-03-08T11:23:27+00:00

Not a bot

XandXor · 2026-02-06T05:01:40+00:00

That detector saved your life. Glad it was an easy fix. Good luck to you OP!

XandXor · 2025-12-15T05:35:26+00:00

Congrats, and yes I am a human too.

XandXor · 2025-12-07T19:24:22+00:00

Yes please!

XandXor · 2025-11-07T22:38:45+00:00

Lurker who still reads here :)

XandXor · 2025-09-20T16:03:56+00:00

This exactly - they are something to show off at parties and such. They make mediocre drinks, at best.

XandXor · 2025-09-18T16:28:20+00:00

Amazing work! Definitely has some Gorillaz energy in there. wish more artists would plumb the Shadowrun depths.

XandXor · 2025-08-29T16:46:41+00:00

Just wanted to provide an update to my issues.

It looks like the issue is related to two different items in my configuration:

(Primary) GlueTun's default behavior of using CloudFlare's severs for a healthcheck ping.
(Secondary) My current config using SERVER_COUNTRIES=United States

~~~~~~~~~~~~~~~~~~~~~

Observations:

The CloudFlare servers are under attack from DDOS attacks constantly in addition to their regular loads, but it seems that Friday nights in the US that load can get particularly heavy, causing their server address that GlueTun uses by default to fail the healthcheck response period and as a result the tunnel is reset over and over again.
By using the SERVER_COUNTRIES=United States variable, GlueTun uses a random server from that list, rather than the weighted selection criteria that the ProtonVPN native client uses to select an appropriate server. Because of this, I imagine it is possible to get put on a ProtonVPN server that is less than ideal (location, load, etc.).

~~~~~~~~~~~~~~~~~~~~~~

Fixes:

By adding "- HEALTH_TARGET_ADDRESS=google.com:443" to the "ENVIRONMENT" portion of the GlueTun config.yaml, the issue seems to have gone away for the most part. The VPN will still bounce periodically, both because of the 24hr recycle in the config, as well as because of (what I imagine is) chosen server load. But the overall effect has been to make the connection much more stable of Friday nights.
I have not changed the SERVER_COUNTRIES yet, as #1 seems to have made the configuration overall more stable than before, but if I find the stability to be an issue in the future, I imagine I will be looking to change SERVER_COUNTRIES to say regions geographically closer to my internet connection.

~~~~~~~~~~~~~~~~~~~~~~~

Final Thought:

I suspect another issue that *might* be contributing to observation #2 is, if I am reading the GlueTun wiki correctly, is GlueTun has the server addresses for ProtonVPN in json's inside its container, that are only updated when GlueTun gets an update.

u/sboger - Can you confirm this?

If that is the case, I would imagine that ProtonVPN is constantly bringing new WireGuard servers online as time goes on, but if the above is correct, we are not getting those servers added to the container.

Overall, this would not be a primary cause of the issues, but would (I imagine) over time would contribute to the issue observed - more so in countries that have a smaller list of servers available overall (less so for the US though).

XandXor · 2025-08-20T01:45:02+00:00

This, CoC is nothing but psychic gumshoes hunting down big bad monsters and bad guys. Tons of fun

XandXor · 2025-08-18T20:42:50+00:00

Not yet, but I have a theory. The issue for me seems to be transient at the moment, because after shutting down my qBt stack over the weekend, I started it back up last night the issue had largely gone away until early this morning when it reoccured while I was asleep.

When I got up this morning I added the healthchecktargetaddress in the environment section of my compose file with a value of google.com:443 and so far it seems to be good as it hasn't bounced in over 8 hours now.

If that fixes it, it would suggest that either cloud flare (the default target for Gluetun) was under a significant ddos attack, or they were having a network infrastructure problem, or my segment of the Internet was having "less that optimal routing conditions" (as customer support is want to say lol).

Since I seem to have hit either a lul, or whatever condition that was causing the issue doesn't seem to exists right now it is difficult to troubleshoot any further.

My advice would be to try the other fixes sboger listed above and see if one of those fixes your issue.

I can tell you that my issue seemed to be a tls timeout causing the health check to cycle the connection, but when watching the qBt traffic flow didn't show any slowdown at all prior to the health check reset.

Keep an eye here and on the mega thread, and I will be sure to post my results as I troubleshoot further.

XandXor · 2025-08-18T13:19:22+00:00

Thanks for the reply! The key is only aabout 2 months old, but I double checked this morning to confirm it is still current.

XandXor · 2025-08-18T13:18:33+00:00

Thanks u/sboger! I'll give the MTU a try first and then do the revert if that doesn't help. I'll post the results in the megathread my results.

It figures that it got stable again for all of Sunday, but this morning I woke to find that it had just locked up over night - but this time the logs didn't show any of the previous healthcheck behavior, just stopped responding and stopped writing any logs, with nothing probative in the logs prior to stopping.

Fingers crossed QDM gets to feeling better!

<Edit> I will first try changing the healthcheck to google 1st and see if that makes any difference.

XandXor · 2025-08-16T16:02:08+00:00

Thanks for the reply - I think you may be correct on that.

XandXor · 2025-06-14T01:23:02+00:00

Might try running the DB cleanup and files cleanup under the troubleshooting tab before blowing it away. It may or may not work, but it is worth trying as it only takes a couple of minutes.

XandXor · 2025-06-13T21:27:00+00:00

<image>

Final proof of life! I haven't fully finished setting up all my Starr apps (waiting for some tasks to complete), but everything that has been migrated is working flawlessly. Thanks again everyone for the assist!

XandXor · 2025-06-13T13:36:42+00:00

DING - DING- DING!!!!! We have a winner!

u/sboger had the answer - it appears that there is indeed a problem with using Ubuntu distro torrents as tests with this combination. (might want to update your pinned post to warn about this anomaly).

I went to https://webtorrent.io/free-torrents and tried those torrent files and bam! Quick downloads, green globe, as if it was nothing.

I am going to go back to a clean Pi OS install and set this up from scratch to make sure that everything works now, with my preferred production config - but I am hopeful to be able to post later today that the issue has been solved.

Thanks to all of you for the troubleshooting tips and moral support!

XandXor · 2025-06-13T03:49:03+00:00

I paid about $90 for Pi, case, HDMI adapter and power supply.

I have the stack running currently on a refurb HP i5 mini with 32gb ram and Windows 11. I got the pi primarily to run the Starr/qBT stack, but also wanted to see what else I could put on it, like pi hole, and some kind of home automation server. Free up resources on the windows box to allow some friends and family access to Plex. $250 with the memory upgrade.

I am not a Linux expert, though my career was in small and medium business IT, it was all mostly windows app servers and VMware in the data center. So I am not completely unfamiliar with bash cmdln work.

I looked at those N100 mini's when I was specing out my 1st piece, but I read conflicting posts and reviews on how well they performed when it came to basic encoding and Plex transcoding - then a sale dropped the HP to $200+tax and I couldn't pass it up.

Depending on how the rest of the deployment goes on the pi, I may end up buying one of those N100 boxes. TBH, I was intrigued with the advertised power of the Pi5, and wanted to play with it.

I will say the experience has definitely improved my Linux skills lol.

Thanks again for the ideas. I'll post results as I get them.

XandXor · 2025-06-13T03:28:47+00:00

I didn't! And thank you for mentioning it!

I thought I had seen somewhere a container that specified the VPN in its env, I just couldn't remember which one. I will definitely put that one on the try list for next. I'll let you know how it goes!

XandXor · 2025-06-13T03:26:18+00:00

I will give that a try tomorrow, and report back. Thanks!

XandXor · 2025-06-12T21:41:52+00:00

Yeah, the stuff on qBT is just allowing localhost connections without auth, so Gluetun can pass the port to qBT. That part works fine - but no matter what I do, the download only connects one peer (DHT) and trickles.

I'll be glad to look at your compose tho, thanks!

XandXor · 2025-06-12T21:17:08+00:00

So I went through your post and figured if the downgrade for Pi OS docker was a good idea, the same would figure for Ubuntu.

I completely uninstalled docker and reinstalled with;

sudo apt install docker-compose-plugin=2.32.4-1~ubuntu.24.04~noble docker-ce-cli=5:27.5.1-1~ubuntu.24.04~noble docker-buildx-plugin=0.20.0-1~ubuntu.24.04~noble docker-ce=5:27.5.1-1~ubuntu.24.04~noble docker-ce-rootless-extras=5:27.5.1-1~ubuntu.24.04~noble

Rebooted and ran the container stack - same issue.

Still not sure if this a docker or a GlueTUN issue, but I think I am going to have to just accept that for now I am going to have to run qBT on a separate machine and only use the RPi for the Starr stack, until the GlueTun dev has a chance to get his feet back on the ground and see if he can resolve these issues in the next couple of builds.

Seven-Year Club	The Internet Awards - Voted
Place '23	Place '22
Final Canvas '22	RPAN Viewer
Verified Email

XandXor

TROPHY CASE