Most "this service got slow" complaints I see follow the same pattern: someone speed-tests once, at 9pm, on whatever node the client happened to pick, and concludes the whole service went downhill. Sometimes it did get worse. More often, one of three fixable things is going on — and all three take under five minutes to check.
1. You're probably on the wrong node
A Just My Socks subscription ships with several Los Angeles nodes, and they are not equal. The s1/s2 nodes run on ordinary international routing. The s3/s4 nodes use the optimized CN2 GIA / 9929 routes back to China, which is the entire reason most people buy this service instead of a random VPS.
Clients don't always pick s3/s4 by default, and after a subscription refresh some people silently land back on s1. During the evening peak in China (roughly 8–11pm), the gap between the two groups is not subtle: the optimized lines hold up, the regular ones sag. Before judging the service, open your client, look at which node is actually selected, and switch to s3 or s4 manually. Or turn on the URL-test / auto-select group and let the client measure instead of guessing.
2. Test all three networks, not just your own
Latency from China to Los Angeles depends heavily on which carrier's route the traffic takes — China Telecom (CN2 GIA), China Unicom (9929), and China Mobile (CMI) behave like three different internets on a bad night. A node that is fine on Telecom can be miserable on Mobile, and the reverse happens too.
This is why a single ping screenshot proves almost nothing. When I want a quick health check of a subscription, I run a small open-source script I maintain, jms-speedtest. It goes through the Just My Socks data centers, tests latency and packet loss across the three carrier routes, and also checks whether the exit IP still unlocks ChatGPT, Claude, Gemini and the usual streaming services. The unlock check matters more than people think: a node can be fast and still useless to you if its IP has been flagged and every AI chat returns 403.
Packet loss is the number to watch. Latency of 160ms vs 190ms is barely noticeable in real use; 5% packet loss at peak hour absolutely is — it shows up as stalls, retries and video rebuffering that people then describe as "slow."
3. Your routing rules may be wasting the good nodes
The third cause has nothing to do with the service at all. If your Clash or sing-box setup sends everything through the proxy — including domestic sites that should go direct — you burn your monthly traffic on traffic that never needed it, and you add proxy latency to sites that were fast natively.
A maintained rule set fixes this quietly: domestic traffic direct, overseas traffic through the optimized nodes, and AI services pinned to the nodes whose IPs stay unlocked. The rule pack I use and maintain is clash-rules; it is built for Clash Verge Rev / Mihomo and auto-updates from the repository, so it is a set-once thing rather than another subscription to babysit. The setup walkthrough is in the Clash guide.
A five-minute checklist
- Check which node is selected. If it is s1/s2, switch to s3/s4 and retest.
- Run a three-network test and look at packet loss, not just ping.
- Check the AI unlock status of your exit IP if ChatGPT or Claude is the thing failing.
- Make sure domestic traffic is going direct in your rules.
If all four are fine and it is still slow at peak hour, then yes — it may be your plan tier. The LA 500 plan is shared by up to 5 devices; a household quietly running three phones, two laptops and a TV box on it will feel very different from one person on a laptop. That is a sizing problem, not a service problem, and it is cheaper to fix by upgrading (you only pay the difference) than by switching providers and starting over.
Disclosure: I maintain the justmysocks-guide project linked above. Some links in my guides are affiliate links; they do not change the prices or any of the test methodology described here.
Top comments (0)