Thanks for the good report! See https://wikitech.wikimedia.org/wiki/Reporting_a_connectivity_issue for the full list. :)

See [wikitech] for the full list"

Do you mean "Additional troubleshooting" sectional and curl to http? Is this a completely full list or maybe you need something else? The problem is massive, but this is the first user who agreed to run cURL. We should not lose him :)

What is the issue in your own words: see above.
Is the issue intermittent or constant: constant
When did the issue start: 1 month ago
What device are you using: mobile and PC (via mobile as access point)
What network are you connected to? Beeline (only 4G network), Russia, Moscow and Moscow region
What is your public IP: see above
cURL: see above
traceroute: see above
ping: see above

Adding that a, from our esams DC, traceroute to this IP seems to stop before beelive.ru

$ traceroute 83.220.238.125
traceroute to 83.220.238.125 (83.220.238.125), 30 hops max, 60 byte packets
 1  ae1-100.cr2-esams.wikimedia.org (91.198.174.3)  0.607 ms  0.579 ms  0.559 ms
 2  mx01.Amsterdam.gldn.net (80.249.209.153)  0.862 ms  3.235 ms  3.224 ms
 3  pe05.KK12.Moscow.gldn.net (79.104.225.13)  41.235 ms  41.473 ms pe05.KK12.Moscow.gldn.net (79.104.225.15)  39.832 ms
 4  62.105.150.251 (62.105.150.251)  41.938 ms  39.834 ms  40.083 ms
 5  * * *

And the last IP in the hop is from a company

inetnum:        62.105.150.248 - 62.105.150.255
netname:        RU-SOVINTEL-MSK-Poliplastik-Group-NET
descr:          119034 Russia Moscow, ZC-5724343
descr:          Ochakovskoe sh, 18, KL-1943598
descr:          POLYPLASTIC GROUP Ltd., http://www.polyplastic.ru
country:        RU
admin-c:        PFoA1-RIPE
tech-c:         PFoA1-RIPE
status:         ASSIGNED PA
mnt-by:         SOVINTEL-MNT
created:        2012-07-20T08:49:57Z
last-modified:  2012-07-20T08:49:57Z
source:         RIPE # Filtered

That handles plastic pipes per http://www.polyplastic.ru/ ?

The AS of beelive.ru is AS16345 and is advertised fine to us per our BGP routing tables. The AS of that company is AS8350 and is NOT part of the AS path we have for 83.220.238.125. This is starting to look like misconfiguration at Sovintel (the upstream of polyplastic judging by whois, and probably one of beelines.ru upstreams as well)

I think the "poliplastic" track a red herring, even though those few IPs are assigned to them in whois, it's used by AS3216, AS16345's upstream, most likely as router IPs.
The fact that the traceroute from us to 83.220.238.125 stops is probably due to the NAT gateway (or something on the way) blocking ICMP.
The fact that pings and traceroutes from them to us works, indicates that routing is most likely fine.

My guess so far would be a middle box (tcp optimization or similar) not working as expected.
We know that https to text-lb.esams times out, now we can try to test other sites/protocols.

Please try:

• http with the same endpoint: curl -v http://en.wikipedia.org/wiki/Main_Page
• https on a different site: curl -v https://text-lb.ulsfo.wikimedia.org --insecure
• http on a different site: curl -v http://text-lb.ulsfo.wikimedia.org
• https on the same site but different endpoint: curl -v https://upload-lb.esams.wikimedia.org --insecure
• http on the same site but different endpoint: curl -v http://upload-lb.esams.wikimedia.org

Once we have those information, we can think of a next step.

Note for anyone who wants to help, please make sure you're on the same network that the one having issues, for that browse https://bgp.he.net/ and make sure it says Your ISP is AS16345

Ciao @ayounsi!
It is possible that CommRel can help you finding someone to diagnose this tomorrow if @Iluvatar doesn't happen to find others to test in the meantime.

(edited to remove confusing information.)

In T214459#4903299, @ayounsi wrote:

Please try:

• http with the same endpoint: curl -v http://en.wikipedia.org/wiki/Main_Page
• https on a different site: curl -v https://text-lb.ulsfo.wikimedia.org --insecure
• http on a different site: curl -v http://text-lb.ulsfo.wikimedia.org
• https on the same site but different endpoint: curl -v https://upload-lb.esams.wikimedia.org --insecure
• http on the same site but different endpoint: curl -v http://upload-lb.esams.wikimedia.org

See https://disk.yandex.by/d/Scrhfdy0BBYdAQ

(Putting this in different order so that it's potentially more understandable by other people without a deep tech knowledge, who may be willing to contribute information:)

Step 0:

In T214459#4903299, @ayounsi wrote:

Note for anyone who wants to help, please make sure you're on the same network that the one having issues, for that browse https://bgp.he.net/ and make sure it says Your ISP is AS16345

Step 1: Head to https://wikitech.wikimedia.org/wiki/Reporting_a_connectivity_issue to learn how to file an accurate report if you haven't done before.

Step 2:

Please try:

• http with the same endpoint: curl -v http://en.wikipedia.org/wiki/Main_Page
• https on a different site: curl -v https://text-lb.ulsfo.wikimedia.org --insecure
• http on a different site: curl -v http://text-lb.ulsfo.wikimedia.org
• https on the same site but different endpoint: curl -v https://upload-lb.esams.wikimedia.org --insecure
• http on the same site but different endpoint: curl -v http://upload-lb.esams.wikimedia.org

Once we have those information, we can think of a next step.

In T214459#4904249, @Iluvatar wrote:

See https://disk.yandex.by/d/Scrhfdy0BBYdAQ

Thank you, it's very curious.

Could you try curl http://www.google.com and curl https://www.google.com --insecure as control? (to be sure other sites work as expected).
Then telnet 198.35.26.96 80 and telnet 198.35.26.96 443 and telnet 91.198.174.113 22

Problem solved. The user received today a new answer to one of many his letters to Support: "we reloaded GPRS settings". Connection is restored. 1 month later...
Thanks to all.