[X] My Assistant

ISPs in mainland China are currently cracking down hard on PCDN usage (I understand this client isn't PCDN, but ISPs don't distinguish them).
As a long-time user since 2016, I've also been affected - my home network's upload speed has been throttled to 5Mbps.

To avoid complete disconnection (it's nearly impossible to get a public IP for new residential connections now),
I've had to follow "insider" suggestions by stopping the client for about 7 days monthly to bypass ISP detection systems.

However, the ehwiki's client operation guidelines aren't clear about shutdown protocols, so I'm seeking clarification here.

P.S. It would be great if future versions could function without public IPv4 and add IPv6 support (IMG:[invalid] style_emoticons/default/biggrin.gif)

https://ehwiki.org/wiki/H@H

It says,

Uptime A single client should remain online for at least 90% of the time over a 6 month period. Clients that have an unacceptable level of downtime will be revoked.

7 days / 30 days = 23% downtime, so it is clear that this isn't supported.

https://ehwiki.org/wiki/H@H

It says,
7 days / 30 days = 23% downtime, so it is clear that this isn't supported.

Alright, your cold shower of reality has successfully killed my wishful thinking. Guess I'll have to ask Tenboro for a client shutdown. (IMG:[invalid] style_emoticons/default/anime_cry.gif)

From the looks of it, the 'purge' on my end isn't ending anytime soon.

Or have Tenboro revise the uptime requirement or give an exception to it. Maybe the proposed uptime pattern would be acceptable based on how H&H operates. If all chinese ISPs are doing this then it needs to be addressed or ehg will lose all hosts in China because of this.

It might be warranted to make a exception for China, yeah, considering the situation there. Also, 90% is not a hard cutoff for clients being revoked, as long as your cache stays intact it could drop a bit below that without anything happening.

Or have Tenboro revise the uptime requirement or give an exception to it. Maybe the proposed uptime pattern would be acceptable based on how H&H operates. If all chinese ISPs are doing this then it needs to be addressed or ehg will lose all hosts in China because of this.

It might be warranted to make a exception for China, yeah, considering the situation there. Also, 90% is not a hard cutoff for clients being revoked, as long as your cache stays intact it could drop a bit below that without anything happening.

The current challenge is that ISPs' PCDN detection is based on upload volume, with surprisingly low thresholds (reaching as little as 1TB weekly upload to trigger, and the actual limit might be even lower). This fundamentally conflicts with the client's operational requirements.

My proposed workaround is to route all client uploads through a secondary network without public IPv4 addresses, while reserving the public IPv4-enabled network only for receiving server messages and minimal uploads.

To avoid complete disconnection (it's nearly impossible to get a public IP for new residential connections now),
I've had to follow "insider" suggestions by stopping the client for about 7 days monthly to bypass ISP detection systems.

Stopped and? Did that lift your uplink limitation?

My proposed workaround is to route all client uploads through a secondary network without public IPv4 addresses, while reserving the public IPv4-enabled network only for receiving server messages and minimal uploads.

How could that be possible, can you explain? How could clients connect to it actively if it's behind a NAT forbidding incoming connections?

Stopped and? Did that lift your uplink limitation?
How could that be possible, can you explain? How could clients connect to it actively if it's behind a NAT forbidding incoming connections?

My host machine has two NICs:Intel i350 and Killer 1550, each connected to separate network accounts - one without public IP and another with public IP address allocation.
By adjusting the HOPS parameter on network interfaces, I can control which NIC takes priority for system network access. A friend of mine claims he can achieve segregated upload/download routing through dedicated NICs, and I'm currently fine-tuning this setup..

emmm,I used DeepSeek to translate my words into English, so there might be some linguistic bugs.

This post has been edited by ChairmanMiao: May 27 2025, 15:57

achieve segregated upload/download routing through dedicated NICs, and I'm currently fine-tuning this setup..

So this strategy hasn't been practiced yet.

Still haven't answered questions about incoming connections.

What the NAT/firewall cares about is that who actively started the connection, if you upload or download in a web browser, you started the TCP handshake to a certain host, which is allowed in any NAT.

But for a HTTP server like H@H, the remote hosts are uncertain, they have to say hello to you first...

[en.wikipedia.org] https://en.wikipedia.org/wiki/Network_addre..._of_translation

So this strategy hasn't been practiced yet.

Still haven't answered questions about incoming connections.

What the NAT/firewall cares about is that who actively started the connection, if you upload or download in a web browser, you started the TCP handshake to a certain host, which is allowed in any NAT.

But for a HTTP server like H@H, the remote hosts are uncertain, they have to say hello to you first...

[en.wikipedia.org] https://en.wikipedia.org/wiki/Network_addre..._of_translation

In theory, we only need to enforce all communications between the local HH host and the RPC server to route exclusively through the public IP network（As you said, it takes practice）. This appears achievable via Windows Firewall rules and routing table configurations, though I'm still researching specific tutorials and discussing with friend.