# ProxyPin: a Flutter-based HTTP(S) capture tool for Windows, macOS, Linux, Android and iOS

> ProxyPin is an Apache-2.0 traffic capture client built with Flutter that runs on five platforms and ships a JavaScript scripting hook for rewriting requests and responses. The README is generous about features and thin about setup, certificate handling and script APIs.

**wanghongenpin/proxypin** — Open source free capture HTTP(S) traffic  software ProxyPin, supporting full platform systems

- Repository: https://github.com/wanghongenpin/proxypin
- Stars: 14,027 · Forks: 1,220
- Language: Dart
- License: Apache-2.0
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/wanghongenpin-proxypin

## What ProxyPin captures, and who is meant to open it

ProxyPin is a client-side proxy that sits between an application and a server so you can read and change the HTTP(S) messages passing through. The README lists the target jobs plainly: intercept, inspect and rewrite traffic, with a specific note that it supports capturing Flutter app traffic. That last point matters because Flutter apps on mobile do not always route through the system proxy the way a native app does, and a tool that advertises Flutter capture is aimed at people debugging their own mobile builds.

The intended user is not a backend engineer tailing logs on a server. It is someone holding a device: a QA engineer reproducing a bug on an Android phone, a mobile developer checking what an SDK sends, a security reviewer looking at what leaves an app. The feature list backs this up. Mobile scan code connection exists so you do not configure a WiFi proxy by hand on the phone. Domain name filtering exists so you intercept only the host you care about and leave other apps alone. History is saved automatically, and the README says HAR export and import are supported, which is the format most other capture tools also read.

ProxyPin is developed in Dart on Flutter, and the repository layout confirms it: android/, ios/, linux/, macos/ and windows/ directories sit next to lib/, with pubspec.yaml at the root. That is a single codebase producing five platform builds. The README also calls the UI beautiful and easy to use, which is a claim about taste rather than a measurable property; treat it as marketing and judge from the screenshots in the repository.

## How the proxy, filtering and rewriting pipeline is arranged

The mechanism the README describes is a man-in-the-middle proxy. Traffic from a client is pointed at ProxyPin, ProxyPin terminates the connection, and to read HTTPS bodies it must present its own certificate to the client. The README does not explain certificate installation in the main text, and that silence is the single biggest gap in the document. Anyone who has set up Charles or Fiddler knows the step exists: generate or export the CA, install it on the device, and on Android and iOS also mark it as trusted for user or system traffic depending on the OS version. ProxyPin users are asking about exactly this, judging by the related search phrases for proxypin certificate and proxypin ca, so the information is clearly needed and clearly not in the README body.

Once traffic is flowing, the pipeline is filter, inspect, then act. Domain name filtering narrows what gets recorded. Search runs over requests by keyword and response type. Then four separate features can change what happens: Script runs JavaScript against a request or response, Request Rewrite handles redirection and replacement of request or response content, Request Mapping answers from local configuration or a script without contacting the remote service, and Request Blocking drops a request by URL before it reaches the server. Request Decryption takes an AES key and decrypts the message body automatically, which is a narrower feature than the name suggests: it only helps when the payload is AES-encrypted with a key you already have.

The scripting hook is the most interesting and the least documented part. The README says JavaScript scripts can process requests or responses, and stops there. There is no example script, no list of the objects or functions a script receives, and no statement about which JavaScript engine runs the code. The repository does contain SKILL.md and AGENTS.md at the top level, which suggests the maintainer has written guidance for agents or contributors, but the README does not point readers to them. If scripting is why you are evaluating ProxyPin, open lib/ and read the script bindings before you commit.

## Installing ProxyPin and making a first capture

ProxyPin is distributed as prebuilt binaries, not as a package you install from a language ecosystem. The README lists GitHub Releases at https://github.com/wanghongenpin/proxypin/releases, the iOS App Store listing, and the Android Google Play listing. There is no Homebrew formula, no apt package and no npm or pub package mentioned, so do not expect one. The current release line is v1.3.2.

Start by downloading the build for your desktop platform from the Releases page. On macOS the README gives one concrete instruction, and it is worth quoting because it is the first thing that will stop you:

```bash
# macOS first launch
# System Settings > Privacy & Security > Allow applications from any source
```

The README states that Mac will prompt about an untrusted developer when first opened and that you need to go to System Preferences, Security & Privacy, and allow any source. If you skip that, the app will not open.

On mobile, the README's selling point is that you do not configure a WiFi proxy manually. The workflow it describes is scan code connection: one terminal displays a code, another scans it, and the connection and its configuration are transferred. That is how you point a phone at a desktop running ProxyPin, or move traffic between terminals.

For a first real capture, the README's own order of operations is the guide: connect the client, then narrow with domain name filtering before you look at anything, because the README explicitly warns that without filtering you interfere with other applications. After that, use Search to find the request, and History to go back to it later. If you need to keep the session, the README says HAR export is supported, so the capture can be reopened in another tool that reads HAR.

## Where ProxyPin is the wrong tool

The first limitation is documentation depth. The README is a feature list. It documents what each feature does in one line and does not document how to configure it, what the edge cases are, or what happens when a step fails. Certificate installation, the JavaScript API surface, the AES decryption key format, and the HAR export fields are all unstated. The related search phrases for proxypin certificate, proxypin ca, proxypin script and ProxyPin config exist precisely because the README does not answer them. A tool can be good and still be a poor choice for a team that needs a written procedure it can hand to a new hire.

Second, the platform reach is wider than the verification story. Five platforms from one Dart codebase means five places for platform-specific behaviour, and the README's only platform-specific note is about macOS gatekeeper. Nothing is said about Windows certificate stores, Linux trust stores, or Android versions where user-installed certificates are ignored by apps. That last case is common and it is not addressed.

Third, this is a GUI application. There is no CLI documented in the README, which rules it out for CI pipelines, scripted regression capture, or headless servers. If your capture step needs to run unattended on a build machine, ProxyPin is not the tool.

Fourth, the README's own warning about interference is a real operational constraint, not a footnote. A capture proxy that sees all traffic will affect applications that do not tolerate interception, and certificate pinning will simply fail. Domain filtering mitigates this but does not remove it.

## ProxyPin against mitmproxy and Charles

The honest comparison is with mitmproxy and Charles Proxy, and the difference is where the control lives.

mitmproxy is a Python program with a console interface and a scripting layer in Python. Its capture, replay and rewrite logic is written as code you keep in version control, and it runs headless. The trade-off is that there is no polished desktop UI and no phone app; you drive it from a terminal and install its certificate the same manual way. If your workflow is automated or you want the capture logic to be reviewed like source, mitmproxy is the stronger fit and ProxyPin is not competing there at all.

Charles Proxy is the closest match in spirit: a commercial GUI capture tool with a mature certificate workflow and long-standing documentation. ProxyPin's difference is that it is free, Apache-2.0 licensed, and built for phones as much as desktops, with the scan code connection removing the manual WiFi proxy step. The cost of that difference is documentation maturity.

Against both, ProxyPin's distinctive combination is the cross-platform Flutter build plus the mobile-first connection flow plus the explicit Flutter app capture support. If you are debugging a Flutter app on a physical phone and you want the same tool on your laptop, that combination is the reason to pick it. If you are capturing traffic in a script, none of those advantages apply.

## Maintenance, release cadence and licence cost

The repository is not archived. The last push was on 2026-09-21, the same day as the v1.3.2 release, and the two releases before it were v1.3.1 on 2026-07-29 and v1.3.0 on 2026-07-06. That is a release roughly every six to eight weeks across that window, which is a real cadence rather than a one-off. It also means the project moves, and a moving capture tool is one you should pin: download a specific release tag rather than whatever the Releases page shows first, because the README documents no rollback procedure and no compatibility promise between versions.

The licence is Apache-2.0, stated in the README badge area and in the LICENSE file at the repository root. That is a permissive licence with an explicit patent grant and a requirement to preserve notices when you redistribute. It does not oblige you to publish your own code. The practical implication for a team is that bundling ProxyPin into an internal toolchain is straightforward, but if you fork it and ship the fork, the Apache-2.0 terms travel with it. This is a description of the licence text, not legal advice; read LICENSE and your own counsel's view before redistributing.

Upgrade cost is the harder question. A GUI capture tool that changes its certificate handling or its script bindings between minor versions can invalidate a saved workflow, and the README gives no migration notes. The repository does carry analysis_options.yaml, pubspec.lock and a test/ directory, so a build from source is possible with the Flutter toolchain, but the README does not describe that path. If you need reproducible behaviour across a team, build from a pinned commit rather than tracking releases.

## Conclusion

ProxyPin fits engineers who need to inspect traffic from a phone or a Flutter app and want the same tool on desktop and mobile, and who are willing to read the source when the README stops short. It is the wrong choice if you need a documented scripting API, a stable plugin surface, or a capture stack you can drive entirely from a terminal. Before adopting it, verify three things in the repository: how the CA certificate is installed on each platform, what the JavaScript script object actually exposes in lib/, and whether the HAR export preserves the fields you need. The README points to GitHub Releases and the two app stores as the only distribution channels, and says nothing about rollback, so pin the release tag you download.

## FAQ

### What does ProxyPin do?

ProxyPin is an open source, free HTTP(S) traffic capture tool. The README says you can use it to intercept, inspect and rewrite HTTP(S) traffic, and that it supports capturing Flutter app traffic.

### How do I use ProxyPin?

Download a build from GitHub Releases or from the iOS App Store or Google Play, then connect a client. The README describes mobile scan code connection so you do not configure a WiFi proxy by hand, and domain name filtering so you only intercept the traffic you need.

### What is ProxyPin built with?

ProxyPin is developed with Flutter, and the repository lists Dart as its primary language. The top-level layout includes android/, ios/, linux/, macos/ and windows/ directories alongside lib/ and pubspec.yaml.

### Is ProxyPin safe to use?

ProxyPin is Apache-2.0 licensed and the README states it is open source, so the source is available to review. The README does not make any security claims about the tool itself, and since it works by terminating HTTPS connections with its own certificate, you install and trust that certificate on the client.

### What can I use instead of ProxyPin?

mitmproxy and Charles Proxy cover the same ground. mitmproxy is driven from a terminal and scripted in Python, while Charles is a commercial GUI tool; ProxyPin's difference is that it is free, Apache-2.0, and built for phones as well as desktops.

## Sources

- [Issues](https://github.com/wanghongenpin/proxypin/issues)
- [License: Apache-2.0](https://github.com/wanghongenpin/proxypin/blob/main/LICENSE)
- [README](https://github.com/wanghongenpin/proxypin/blob/main/README.md)
- [Releases](https://github.com/wanghongenpin/proxypin/releases)
- [wanghongenpin/proxypin on GitHub](https://github.com/wanghongenpin/proxypin)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/wanghongenpin-proxypin