Issues with displaying website through the proxy #84

OnkelTem · 2022-05-19T10:49:42Z

I created a simple passthrough proxy and try to use it with FF.

The problem is, that for some reason the https://twitter.com website doesn't load at all or loads partially when the proxy is used.
I cannot identify the reason, this is what I see in the logs:

Proxying HTTP/1 CONNECT to twitter.com:443
Generating certificate for twitter.com
Handling request for https://twitter.com/
Request matched rule: Match requests for anything, and then pass the request through to the target host.

and then after a long delay:

Failed to handle request: Error: connect ETIMEDOUT 104.244.42.65:443
    at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1157:16) {
  errno: -110,
  code: 'ETIMEDOUT',
  syscall: 'connect',
  address: '104.244.42.65',
  port: 443,
  statusCode: 502,
  statusMessage: 'Error communicating with upstream server'
}
Failed to handle request: Error: connect ETIMEDOUT 104.244.42.65:443
    at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1157:16) {
  errno: -110,
  code: 'ETIMEDOUT',
  syscall: 'connect',
  address: '104.244.42.65',
  port: 443,
  statusCode: 502,
  statusMessage: 'Error communicating with upstream server'
}
Failed to handle request: Error: connect ETIMEDOUT 104.244.42.65:443
    at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1157:16) {
  errno: -110,
  code: 'ETIMEDOUT',
  syscall: 'connect',
  address: '104.244.42.65',
  port: 443,
  statusCode: 502,
  statusMessage: 'Error communicating with upstream server'
}
Failed to handle request: Error: connect ETIMEDOUT 104.244.42.65:443
    at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1157:16) {
  errno: -110,
  code: 'ETIMEDOUT',
  syscall: 'connect',
  address: '104.244.42.65',
  port: 443,
  statusCode: 502,
  statusMessage: 'Error communicating with upstream server'
}

FF outout:

Now, if I enable the system level VPN, it does start working!
So basically twitter.com without proxy works, and also it works with proxy with VPN

It seems like FF can do something that http://twitter.com requires, but what my proxy (or the underlying mockttp) can't do. What it could be? Does anyone have any idea?

This is my source code:
https://github.com/OnkelTem/passthrough-web-proxy

The text was updated successfully, but these errors were encountered:

pimterry · 2022-05-19T11:03:29Z

Now, if I enable the system level VPN, it does start working!

What VPN is this?

Do you have another proxy configured on your system at all?

What happens if you try to connect directly to that address without the VPN running:

Does ping 104.244.42.65 work?

What happens if you run node and then:

require('https').get('https://twitter.com').on('response', () => console.log('got response')).on('error', console.log)

I suspect that you have some kind of upstream proxy that's required for internet access, and while other software (Firefox) automatically detects your system settings, Node.js doesn't (this is a general problem: nodejs/node#8381).

In that case, you'll need to detect your system proxy and provide a proxyConfig option to the passthrough rule: https://httptoolkit.github.io/mockttp/interfaces/requestHandlerDefinitions.PassThroughHandlerOptions.html#proxyConfig. That's normally something like thenPassThrough({ proxyConfig: { proxyUrl: 'http://myproxy.com:1234' } }).

OnkelTem · 2022-05-19T16:50:52Z

About proxies

No, I don't use any VPNs or Proxies usually, but I enable a VyprVPN system-level VPN (through Network Manager) for testing when I have some suspicions.

So the only proxy enabled in my FF is the passthrough one, on 127.0.0.1:8000

I made a few more tests, and while I'm not succeeded yet in nailing down the reason, I figured out one interesting thing.
So I was using the URL https://abs.twimg.com/ for my tests, because I suspected it might be one of the culprits.

When FF is not configured to use a proxy, a request to https://abs.twimg.com/ is made using HTTP/2. Here is a sample response:

        HTTP/2 400 Bad Request
        cache-control: no-cache, no-store, max-age=0
        date: Thu, 19 May 2022 12:48:30 UTC
        server: tsa_b
        strict-transport-security: max-age=631138519
        timing-allow-origin: https://twitter.com, https://mobile.twitter.com
        x-connection-hash: 8e75cd5ab23918ca9b480a099ea158262ccc8597e994de3fe4f5e7da5e795ebf
        x-response-time: 5
        content-length: 0
        X-Firefox-Spdy: h2

But when I enable the proxy in FF, it seems to switch immediately back to HTTP/1.1:

        HTTP/1.1 400 Bad Request
        cache-control: no-cache, no-store, max-age=0
        date: Thu, 19 May 2022 12:47:15 UTC
        server: tsa_b
        strict-transport-security: max-age=631138519
        timing-allow-origin: https://twitter.com, https://mobile.twitter.com
        x-connection-hash: c64170edf2164b7873be5059046cdf545781f1b51712199b68b50feb30820422
        x-response-time: 6
        Content-Length: 0

The 400 code is not important in this case, but it seems like FF supports only HTTP/1.1 proxies.

Connecting to https://twitter.com

As for the suggested script:

require('https')
  .get('https://twitter.com')
  .on('response', () => console.log('got response'))
  .on('error', console.log);

It cannot connected to the peer and nothing appears on the stdout.

Here is the strace output:

(master % u=)$ strace -t -f -e trace=network node 1.js
strace: Process 2105982 attached
strace: Process 2105983 attached
strace: Process 2105984 attached
strace: Process 2105985 attached
strace: Process 2105986 attached
strace: Process 2105987 attached
strace: Process 2105988 attached
strace: Process 2105989 attached
strace: Process 2105990 attached
strace: Process 2105991 attached
[pid 2105988] 19:46:56 socket(AF_NETLINK, SOCK_RAW|SOCK_CLOEXEC, NETLINK_ROUTE) = 18
[pid 2105988] 19:46:56 bind(18, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 0
[pid 2105988] 19:46:56 getsockname(18, {sa_family=AF_NETLINK, nl_pid=2105981, nl_groups=00000000}, [12]) = 0
[pid 2105988] 19:46:56 sendto(18, {{len=20, type=RTM_GETADDR, flags=NLM_F_REQUEST|NLM_F_DUMP, seq=1652978816, pid=0}, {ifa_family=AF_UNSPEC, ...}}, 20, 0, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 20
[pid 2105988] 19:46:56 recvmsg(18, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base=[{{len=76, type=RTM_NEWADDR, flags=NLM_F_MULTI, seq=1652978816, pid=2105981}, {ifa_family=AF_INET, ifa_prefixlen=8, ifa_flags=IFA_F_PERMANENT, ifa_scope=RT_SCOPE_HOST, ifa_index=if_nametoindex("lo")}, [{{nla_len=8, nla_type=IFA_ADDRESS}, inet_addr("127.0.0.1")}, {{nla_len=8, nla_type=IFA_LOCAL}, inet_addr("127.0.0.1")}, {{nla_len=7, nla_type=IFA_LABEL}, "lo"}, {{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_PERMANENT}, {{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=4294967295, ifa_valid=4294967295, cstamp=683, tstamp=683}}]}, {{len=88, type=RTM_NEWADDR, flags=NLM_F_MULTI, seq=1652978816, pid=2105981}, {ifa_family=AF_INET, ifa_prefixlen=24, ifa_flags=0, ifa_scope=RT_SCOPE_UNIVERSE, ifa_index=if_nametoindex("enp7s0")}, [{{nla_len=8, nla_type=IFA_ADDRESS}, inet_addr("192.168.88.29")}, {{nla_len=8, nla_type=IFA_LOCAL}, inet_addr("192.168.88.29")}, {{nla_len=8, nla_type=IFA_BROADCAST}, inet_addr("192.168.88.255")}, {{nla_len=11, nla_type=IFA_LABEL}, "enp7s0"}, {{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_NOPREFIXROUTE}, {{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=61599, ifa_valid=61599, cstamp=1204, tstamp=69323089}}]}, {{len=88, type=RTM_NEWADDR, flags=NLM_F_MULTI, seq=1652978816, pid=2105981}, {ifa_family=AF_INET, ifa_prefixlen=16, ifa_flags=IFA_F_PERMANENT, ifa_scope=RT_SCOPE_UNIVERSE, ifa_index=if_nametoindex("docker0")}, [{{nla_len=8, nla_type=IFA_ADDRESS}, inet_addr("172.17.0.1")}, {{nla_len=8, nla_type=IFA_LOCAL}, inet_addr("172.17.0.1")}, {{nla_len=8, nla_type=IFA_BROADCAST}, inet_addr("172.17.255.255")}, {{nla_len=12, nla_type=IFA_LABEL}, "docker0"}, {{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_PERMANENT}, {{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=4294967295, ifa_valid=4294967295, cstamp=1266, tstamp=1266}}]}, {{len=88, type=RTM_NEWADDR, flags=NLM_F_MULTI, seq=1652978816, pid=2105981}, {ifa_family=AF_INET, ifa_prefixlen=24, ifa_flags=IFA_F_PERMANENT, ifa_scope=RT_SCOPE_UNIVERSE, ifa_index=if_nametoindex("tun0")}, [{{nla_len=8, nla_type=IFA_ADDRESS}, inet_addr("10.9.10.143")}, {{nla_len=8, nla_type=IFA_LOCAL}, inet_addr("10.9.10.143")}, {{nla_len=8, nla_type=IFA_BROADCAST}, inet_addr("10.9.10.255")}, {{nla_len=9, nla_type=IFA_LABEL}, "tun0"}, {{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_PERMANENT}, {{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=4294967295, ifa_valid=4294967295, cstamp=69325938, tstamp=69325938}}]}], iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 340
[pid 2105988] 19:46:56 recvmsg(18, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base=[{{len=72, type=RTM_NEWADDR, flags=NLM_F_MULTI, seq=1652978816, pid=2105981}, {ifa_family=AF_INET6, ifa_prefixlen=128, ifa_flags=IFA_F_PERMANENT, ifa_scope=RT_SCOPE_HOST, ifa_index=if_nametoindex("lo")}, [{{nla_len=20, nla_type=IFA_ADDRESS}, inet_pton(AF_INET6, "::1")}, {{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=4294967295, ifa_valid=4294967295, cstamp=683, tstamp=683}}, {{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_PERMANENT}]}, {{len=72, type=RTM_NEWADDR, flags=NLM_F_MULTI, seq=1652978816, pid=2105981}, {ifa_family=AF_INET6, ifa_prefixlen=64, ifa_flags=IFA_F_PERMANENT, ifa_scope=RT_SCOPE_LINK, ifa_index=if_nametoindex("enp7s0")}, [{{nla_len=20, nla_type=IFA_ADDRESS}, inet_pton(AF_INET6, "fe80::4f33:2473:ad96:5db5")}, {{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=4294967295, ifa_valid=4294967295, cstamp=1204, tstamp=1404}}, {{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_PERMANENT|IFA_F_NOPREFIXROUTE}]}, {{len=72, type=RTM_NEWADDR, flags=NLM_F_MULTI, seq=1652978816, pid=2105981}, {ifa_family=AF_INET6, ifa_prefixlen=64, ifa_flags=IFA_F_PERMANENT, ifa_scope=RT_SCOPE_LINK, ifa_index=if_nametoindex("docker0")}, [{{nla_len=20, nla_type=IFA_ADDRESS}, inet_pton(AF_INET6, "fe80::42:7dff:fe7a:ab5c")}, {{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=4294967295, ifa_valid=4294967295, cstamp=53156258, tstamp=53156258}}, {{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_PERMANENT}]}, {{len=72, type=RTM_NEWADDR, flags=NLM_F_MULTI, seq=1652978816, pid=2105981}, {ifa_family=AF_INET6, ifa_prefixlen=64, ifa_flags=IFA_F_PERMANENT, ifa_scope=RT_SCOPE_LINK, ifa_index=if_nametoindex("tun0")}, [{{nla_len=20, nla_type=IFA_ADDRESS}, inet_pton(AF_INET6, "fe80::a326:5f92:5be9:aced")}, {{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=4294967295, ifa_valid=4294967295, cstamp=69325938, tstamp=69325938}}, {{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_PERMANENT|IFA_F_STABLE_PRIVACY}]}], iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 288
[pid 2105988] 19:46:56 recvmsg(18, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base={{len=20, type=NLMSG_DONE, flags=NLM_F_MULTI, seq=1652978816, pid=2105981}, 0}, iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 20
[pid 2105988] 19:46:56 socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 19
[pid 2105988] 19:46:56 connect(19, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid 2105988] 19:46:56 socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 18
[pid 2105988] 19:46:56 connect(18, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid 2105988] 19:46:56 socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 18
[pid 2105988] 19:46:56 setsockopt(18, SOL_IP, IP_RECVERR, [1], 4) = 0
[pid 2105988] 19:46:56 connect(18, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, 16) = 0
[pid 2105988] 19:46:56 sendmmsg(18, [{msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\350\241\1 \0\1\0\0\0\0\0\1\7twitter\3com\0\0\1\0\1\0\0)"..., iov_len=40}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, msg_len=40}, {msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\201\243\1 \0\1\0\0\0\0\0\1\7twitter\3com\0\0\34\0\1\0\0)"..., iov_len=40}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, msg_len=40}], 2, MSG_NOSIGNAL) = 2
[pid 2105988] 19:46:56 recvfrom(18, "\350\241\201\200\0\1\0\1\0\0\0\1\7twitter\3com\0\0\1\0\1\300\f\0"..., 2048, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, [28->16]) = 56
[pid 2105988] 19:46:56 recvfrom(18, "\201\243\201\200\0\1\0\0\0\0\0\1\7twitter\3com\0\0\34\0\1\0\0)"..., 65536, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, [28->16]) = 40
[pid 2105981] 19:46:56 socket(AF_INET, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 18
[pid 2105981] 19:46:56 connect(18, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("104.244.42.129")}, 16) = -1 EINPROGRESS (Operation now in progress)

/// DELAY OF 2 minutes 09 seconds

[pid 2105981] 19:49:05 getsockopt(18, SOL_SOCKET, SO_ERROR, [ETIMEDOUT], [4]) = 0
Error: connect ETIMEDOUT 104.244.42.129:443
    at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1157:16) {
  errno: -110,
  code: 'ETIMEDOUT',
  syscall: 'connect',
  address: '104.244.42.129',
  port: 443
}
[pid 2105984] 19:49:05 +++ exited with 0 +++
[pid 2105986] 19:49:05 +++ exited with 0 +++
[pid 2105985] 19:49:05 +++ exited with 0 +++
[pid 2105983] 19:49:05 +++ exited with 0 +++
[pid 2105982] 19:49:05 +++ exited with 0 +++
[pid 2105989] 19:49:05 +++ exited with 0 +++
[pid 2105990] 19:49:05 +++ exited with 0 +++
[pid 2105991] 19:49:05 +++ exited with 0 +++
[pid 2105988] 19:49:05 +++ exited with 0 +++
[pid 2105987] 19:49:05 +++ exited with 0 +++
19:49:05 +++ exited with 0 +++

OnkelTem · 2022-05-19T16:58:46Z

Anyways, it seems that connections get interrupted by some upstream filtering proxy, imposed by the government.

I even found this nice record in the database of RKN (the officials who initiate the blockages in Russia):

So it shouldn't really work, but.. LOL :)

Finally, here's a few speculations on how it may looks like (just off the top of my head):

So they may block HTTP/1.1 requests only.
And thus when my Mockttp proxy is used AND granted that FF supports only HTTP/1.1 proxies THEN it makes the whole connection be the HTTP/1.1 one and hence - blocking.
But sometimes it works. Which may basically mean, that the upstream blocker doesn't filter out ALL the connections, but just some, depending on its load.
phew...

OnkelTem · 2022-05-19T17:04:17Z

So this one can be closed I suppose, as it doesn't seem to be relevant.
I apologize for spending your time.
Thank you for the quick response and helpful ideas!

pimterry · 2022-05-20T11:39:28Z

Huh, interesting! Interfering government proxies sound very annoying, sorry about that, but yes it looks like HTTP Toolkit is doing the right thing in that case. Connecting upstream directly genuinely times out, and it correctly shows that as the error. I'll close this.

Very interesting that it's intermittent though, I'd be curious to know how they're implementing the block internally to cause that. Maybe it's by IP, and round-robin DNS is sending you to different Twitter IPs each time, and not all of them are blocked?

Anyway, if using a VPN works, that's probably the best option. Alternatively you might find that the proxyConfig option gives you a more direct workaround without needing to remember to use the VPN, if you can find an accessible proxy hosted outside Russia to route around the issue.

OnkelTem changed the title ~~Issue with connecting when using proxy~~ Issues with connecting when using proxy May 19, 2022

OnkelTem changed the title ~~Issues with connecting when using proxy~~ Issues with displaying website through the proxy May 19, 2022

pimterry closed this as completed May 20, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Issues with displaying website through the proxy #84

Issues with displaying website through the proxy #84

OnkelTem commented May 19, 2022 •

edited

Loading

pimterry commented May 19, 2022

OnkelTem commented May 19, 2022 •

edited

Loading

OnkelTem commented May 19, 2022 •

edited

Loading

OnkelTem commented May 19, 2022 •

edited

Loading

pimterry commented May 20, 2022

Issues with displaying website through the proxy #84

Issues with displaying website through the proxy #84

Comments

OnkelTem commented May 19, 2022 • edited Loading

pimterry commented May 19, 2022

OnkelTem commented May 19, 2022 • edited Loading

About proxies

Connecting to https://twitter.com

OnkelTem commented May 19, 2022 • edited Loading

OnkelTem commented May 19, 2022 • edited Loading

pimterry commented May 20, 2022

OnkelTem commented May 19, 2022 •

edited

Loading

OnkelTem commented May 19, 2022 •

edited

Loading

OnkelTem commented May 19, 2022 •

edited

Loading

OnkelTem commented May 19, 2022 •

edited

Loading