starred/Proxyman

Fork 0

mirror of https://github.com/ProxymanApp/Proxyman.git synced 2026-04-27 17:15:49 +03:00

[GH-ISSUE #714] Toggling Block List Drops Non-matching Active Connections #712

New issue

Open

opened 2026-03-03 19:21:12 +03:00 by kerem · 7 comments

kerem commented

2026-03-03 19:21:12 +03:00

Owner

Originally created by @ryanbrainard on GitHub (Dec 2, 2020).
Original GitHub issue: https://github.com/ProxymanApp/Proxyman/issues/714

Originally assigned to: @NghiaTranUIT on GitHub.

Proxyman version? (Ex. Proxyman 1.4.3)

Version 2.14.1 (21410)

macOS Version? (Ex. mac 10.14)

10.14.6 (18G6042)

Steps to reproduce

Stand up a server that can support long connections. To reproduce, we can just use netcat and never respond. In one terminal, run:

nc -l 9191

Establish a connection to the server in another terminal via Proxyman:

curl -x "http://localhost:9090" http://localhost:9191

Confirm the connection shows up in Proxyman as "ACTIVE".
In Proxyman, add and enable a Block List rule that does not match. For example:

ANY http://example/

The connection is killed and the client errors:

curl: (52) Empty reply from server

Expected behavior

Since http://localhost:9191 does not match the blocklist rule ANY http://example/, I would not expect that connection to be dropped. I am trying to block connections to a particular server, but it is dropping active connections to other non-matching servers too.

Originally created by @ryanbrainard on GitHub (Dec 2, 2020). Original GitHub issue: https://github.com/ProxymanApp/Proxyman/issues/714 Originally assigned to: @NghiaTranUIT on GitHub. ### Proxyman version? (Ex. Proxyman 1.4.3) Version 2.14.1 (21410) ### macOS Version? (Ex. mac 10.14) 10.14.6 (18G6042) ### Steps to reproduce 1. Stand up a server that can support long connections. To reproduce, we can just use netcat and never respond. In one terminal, run: `nc -l 9191` 2. Establish a connection to the server in another terminal via Proxyman: `curl -x "http://localhost:9090" http://localhost:9191` 3. Confirm the connection shows up in Proxyman as "ACTIVE". 4. In Proxyman, add and enable a Block List rule that does _not_ match. For example: `ANY http://example/` 5. The connection is killed and the client errors: `curl: (52) Empty reply from server` ### Expected behavior Since `http://localhost:9191` does not match the blocklist rule `ANY http://example/`, I would not expect that connection to be dropped. I am trying to block connections to a particular server, but it is dropping active connections to other non-matching servers too.

kerem commented

2026-03-03 19:21:13 +03:00

Author

Owner

@NghiaTranUIT commented on GitHub (Dec 2, 2020):

Hi @ryanbrainard Thanks for the bug report 👍

However, I tried to reproduce but I could not reproduce on my own.

Your scenario by using nc

Video: https://www.dropbox.com/s/mku82zm0rm3o3i1/Use_NC.mov?dl=0

(Please download for better resolution. I'm not sure why watching on Dropbox is too bad 😅

My localhost server at 3000

Video: https://www.dropbox.com/s/qo396ni5p1upxqr/Use_localhost_3000.mov?dl=0

As you can see in the video, if I enable http://example/, it doesn't block any request from the terminal. On the other hand, if I enable http://localhost:3000 or http://localhost:9191, it will block the connection.

Here is my config:

Can you help me to share your config? I would like to investigate your problem

@NghiaTranUIT commented on GitHub (Dec 2, 2020): Hi @ryanbrainard Thanks for the bug report 👍 However, I tried to reproduce but I could not reproduce on my own. ### Your scenario by using nc Video: https://www.dropbox.com/s/mku82zm0rm3o3i1/Use_NC.mov?dl=0 (Please download for better resolution. I'm not sure why watching on Dropbox is too bad 😅 ### My localhost server at 3000 Video: https://www.dropbox.com/s/qo396ni5p1upxqr/Use_localhost_3000.mov?dl=0 -------------- As you can see in the video, if I enable http://example/, it doesn't block any request from the terminal. On the other hand, if I enable http://localhost:3000 or http://localhost:9191, it will block the connection. Here is my config: <img width="1392" alt="Screen Shot 2020-12-02 at 21 52 50" src="https://user-images.githubusercontent.com/5878421/100888468-bc3b6c00-34e8-11eb-9d3b-667e89c40dd9.png"> Can you help me to share your config? I would like to investigate your problem

kerem commented

2026-03-03 19:21:13 +03:00

Author

Owner

@ryanbrainard commented on GitHub (Dec 3, 2020):

@NghiaTranUIT Thanks for taking a look at this so quickly and trying to reproduce. It looks like the difference in our steps is that I am enabling the non-matching block while the connection is still active. This is why I was using nc to simulate a long-running connection (in the real world, I was experiencing this with a long-polling HTTP client). Here is a video of the issue:

@ryanbrainard commented on GitHub (Dec 3, 2020): @NghiaTranUIT Thanks for taking a look at this so quickly and trying to reproduce. It looks like the difference in our steps is that I am enabling the non-matching block *while the connection is still active*. This is why I was using `nc` to simulate a long-running connection (in the real world, I was experiencing this with a long-polling HTTP client). Here is a video of the issue: ![Proxyman Issue 714](https://user-images.githubusercontent.com/966764/100949591-f4c16100-354d-11eb-8f81-d50c7ff02c41.gif)

kerem commented

2026-03-03 19:21:13 +03:00

Author

Owner

@ryanbrainard commented on GitHub (Dec 3, 2020):

I wanted to mention that I partially worked around the issue using the Scripting feature. In my case, I really only needed to inject an error from the server to the client (not necessarily completely block the request), so I was able to set response.statusCode = 500; in the response script and enable/disable the script. Unlike the Block List, the Scripting feature does not impact other active connections when enabling/disabling.

Even though I didn't really need it, it would be nice to have something in the Scripting feature to reject requests. I'm not exactly sure where it happens in the request lifecycle or if that's possible, but it would be nice to be able to do something like throw new RejectRequest(); or something in the script. Maybe something like this is already possible, but I didn't see it in any of the sample snippets.

@ryanbrainard commented on GitHub (Dec 3, 2020): I wanted to mention that I partially worked around the issue using the Scripting feature. In my case, I really only needed to inject an error from the server to the client (not necessarily completely block the request), so I was able to set `response.statusCode = 500;` in the response script and enable/disable the script. Unlike the Block List, the Scripting feature does not impact other active connections when enabling/disabling. Even though I didn't really need it, it would be nice to have something in the Scripting feature to reject requests. I'm not exactly sure where it happens in the request lifecycle or if that's possible, but it would be nice to be able to do something like `throw new RejectRequest();` or something in the script. Maybe something like this is already possible, but I didn't see it in any of the sample snippets.

kerem commented

2026-03-03 19:21:13 +03:00

Author

Owner

@NghiaTranUIT commented on GitHub (Dec 3, 2020):

@NghiaTranUIT Thanks for taking a look at this so quickly and trying to reproduce. It looks like the difference in our steps is that I am enabling the non-matching block while the connection is still active. This is why I was using nc to simulate a long-running connection (in the real world, I was experiencing this with a long-polling HTTP client). Here is a video of the issue:

Look like I found the problem. The connection is dropped as soon as you enable the Block Rule. At the moment, when the Block List / Allow list is changed, it will close all alive connections to make sure the new connections take effect.

I think it's a problem, Proxyman should not close all connections, but only close the connection that matches the changes.

To work around your problem, please enable the block Rule, and try to start a server again. It should work.

@NghiaTranUIT commented on GitHub (Dec 3, 2020): > @NghiaTranUIT Thanks for taking a look at this so quickly and trying to reproduce. It looks like the difference in our steps is that I am enabling the non-matching block _while the connection is still active_. This is why I was using `nc` to simulate a long-running connection (in the real world, I was experiencing this with a long-polling HTTP client). Here is a video of the issue: > > ![Proxyman Issue 714](https://user-images.githubusercontent.com/966764/100949591-f4c16100-354d-11eb-8f81-d50c7ff02c41.gif) Look like I found the problem. The connection is dropped as soon as you enable the Block Rule. At the moment, when the Block List / Allow list is changed, it will close all alive connections to make sure the new connections take effect. I think it's a problem, Proxyman should not close all connections, but only close the connection that matches the changes. To work around your problem, please enable the block Rule, and try to start a server again. It should work.

kerem commented

2026-03-03 19:21:13 +03:00

Author

Owner

@NghiaTranUIT commented on GitHub (Dec 3, 2020):

Even though I didn't really need it, it would be nice to have something in the Scripting feature to reject requests. I'm not exactly sure where it happens in the request lifecycle or if that's possible, but it would be nice to be able to do something like throw new RejectRequest(); or something in the script. Maybe something like this is already possible, but I didn't see it in any of the sample snippets.

There are a few feature requests to support "Drop connection" in the scripting. I will open the ticket for it 👍

@NghiaTranUIT commented on GitHub (Dec 3, 2020): > Even though I didn't really need it, it would be nice to have something in the Scripting feature to reject requests. I'm not exactly sure where it happens in the request lifecycle or if that's possible, but it would be nice to be able to do something like throw new RejectRequest(); or something in the script. Maybe something like this is already possible, but I didn't see it in any of the sample snippets. There are a few feature requests to support "Drop connection" in the scripting. I will open the ticket for it 👍

kerem commented

2026-03-03 19:21:13 +03:00

Author

Owner

@ryanbrainard commented on GitHub (Dec 3, 2020):

@NghiaTranUIT Thanks for taking a look again.

To work around your problem, please enable the block Rule, and try to start a server again. It should work.

I didn't show it in the steps to keep things simple, but unfortunately, I can't do that because I have connections to multiple servers and I'm trying to just block one of them while leaving the other untouched. The workaround with Scripting works though, so I'm good. Thanks for the help!

There are a few feature requests to support "Drop connection" in the scripting. I will open the ticket for it 👍

Great! Thanks for the great tool!

@ryanbrainard commented on GitHub (Dec 3, 2020): @NghiaTranUIT Thanks for taking a look again. > To work around your problem, please enable the block Rule, and try to start a server again. It should work. I didn't show it in the steps to keep things simple, but unfortunately, I can't do that because I have connections to multiple servers and I'm trying to just block one of them while leaving the other untouched. The workaround with Scripting works though, so I'm good. Thanks for the help! > There are a few feature requests to support "Drop connection" in the scripting. I will open the ticket for it 👍 Great! Thanks for the great tool!

kerem commented

2026-03-03 19:21:13 +03:00

Author

Owner

@NghiaTranUIT commented on GitHub (Dec 3, 2020):

We will improve this behavior: by not close all connections, and just close connections that we enable/disable soon 👍

Thank you 🎉

@NghiaTranUIT commented on GitHub (Dec 3, 2020): We will improve this behavior: by not close all connections, and just close connections that we enable/disable soon 👍 Thank you 🎉