High Ping

[boba1088]

В играх сильно подскакивает пинг при использовании данной программы, причем не важно проксируешь игру или нет, пинг все равно скачет туда сюда от дефолтных 80мс до 999мс. [ProxiFyre-v1.0.25]

[ArisAachen]

i have the same issue
this project handle read package one by one with socks request,
and join them together to mstcp thread

that means the handle time is (n * socks handle time)
that waste too much time
i think it is not good design
a better solution is handle each package parallel

[ArisAachen]

@wiresock

This part of the code may need to be ​​reimplemented​​.

You can reference this project:
https://github.com/imgk/shadow

[wiresock]

Latency spikes are caused by resolving the process context within the packet processing thread—an expensive operation that introduces delays. If your system frequently establishes TCP/UDP connections, such as during torrenting, this can lead to the behavior you observed. I plan to address this issue in an upcoming update.

[wiresock]

Problem

When handling high volumes of TCP and UDP traffic, the previous implementation resolved the process context synchronously within the packet processing path. This approach introduced risks of:

• Blocking critical execution paths
• Deadlocks or race conditions
• Reduced throughput under load

These issues negatively impacted performance, especially on systems with many concurrent connections.

---

Resolution

In ProxiFyre v2.0.1, process context resolution was moved into a deferred execution path. This change ensures that:

• Packet processing remains fast and non-blocking
• Resource-intensive lookups are handled outside the critical path
• System stability and responsiveness are improved under heavy traffic

---

Technical Summary

• Process context lookups for TCP and UDP are now queued and handled asynchronously.
• Packet flow is decoupled from context resolution logic.
• Verified compatibility with multi-interface filtering via queued_multi_interface_packet_filter.

---

Status

✅ Fixed in: v2.0.1
📦 Available via updated binaries and source code.

---

Thanks for your patience, and feel free to open a new issue if you encounter related problems!

[ArisAachen]

in this project, u need to redirect both outgoing and ingoing flow,
in outgoing direction, it record the relation map of src port and flow info,
and in ingoing direction, it replay the flow according to the map

im not sure if it is a good idea

i think may be we only need to redirect outgoing flow

i have implement a go version, seems have a higher performance,
should i send it to u if u are interested?

[wiresock]

Hi @ArisAachen,

Thanks for the explanation!

In my current implementation (ProxiFyre), I only intercept outgoing traffic. That’s sufficient because I’m redirecting it to a local transparent proxy, which then takes over the connection handling. Since the proxy establishes a new connection to the destination server on its own, all incoming packets are naturally received by the proxy, not by the original application. So, there’s no need to manually “replay” or forward the inbound traffic back — it never goes back to the original socket.

From what I understand, your approach sounds closer to a full TCP relay or MITM, where you’re maintaining a connection mapping and replaying traffic manually, possibly in both directions. That’s a different design, and in such cases, handling both directions makes sense.

[ArisAachen]

Thanks @wiresock
Works fine for me....
This issue should be closed?

[wiresock]

Thank you for the feedback, @ArisAachen. If you’re not experiencing any issues with ping latency, feel free to close this issue.