Skip to content
KitploitKITPLOIT
ツールブログ
提出
ツールブログ
提出

ハッキング、侵入テスト、サイバーセキュリティツールをあなたのセキュリティアーセナルに!

Kitploitはハッキング、サイバーセキュリティ、ペネトレーションテストのツールディレクトリです。最新のプロジェクトアップデートを見つけて、脆弱性の発見、システム分析、テストの自動化、セキュリティの強化を行いましょう。

··フィード·お問い合わせ·プライバシー·© 2026 Kitploit

ツールディレクトリ

カテゴリ

すべてのカテゴリを見る
Loading categories
pingap — nginx のようなリバースプロキシ、pingora 上に構築、シンプルで効率的。 | Kitploit
ツール/GitHubGitHub/vicanso/pingap
認証と認可リバースエンジニアリングウェブセキュリティクラウドセキュリティDevSecOps認証APIセキュリティ
GitHubvicanso/pingap

pingap

nginx のようなリバースプロキシ、pingora 上に構築、シンプルで効率的。

リポジトリを見る
1.3k971416時間58分前Kitploit レビュー済み

人気

すべて見る →

コミュニティで最も使われているツールを見つけましょう。

すべてのツールを探索

ツールコレクションを閲覧

すべてのツールを見る →
共有
ウェブサイト

pingap

pingapのバージョンが安定するまでは、プルリクエストは受け付けられません。ご質問がある場合は、まず新しいissueを作成してください。

Pingap Logo

概要

Pingapは、Cloudflare Pingora を搭載した高性能リバースプロキシです。簡潔なTOMLファイルと直感的なWeb管理インターフェースを通じて、動的かつダウンタイムゼロの設定ホットリロードを可能にし、運用管理を簡素化します。

その中核となる強みは強力なプラグインシステムにあり、認証(JWT、Key Auth)、セキュリティ(CSRF、IP/Referer/UA制限)、トラフィック制御(レート制限、キャッシュ)、コンテンツ変更(リダイレクト、コンテンツ置換)、および可観測性(リクエストID)のための20以上のすぐに使える機能を提供します。これにより、Pingapは単なるプロキシではなく、API保護から最新のWebアプリケーション展開まで、複雑なシナリオを難なく処理できるように設計された、柔軟で拡張可能なアプリケーションゲートウェイとなります。

中文说明 | Documentation · 中文文档 | Examples | Plugins | Crates

root@kitploit:~
flowchart LR
  internet("Internet") -- request --> pingap["Pingap"]
  pingap -- proxy:pingap.io/api/* --> apiUpstream["10.1.1.1,10.1.1.2"]
  pingap -- proxy:cdn.pingap.io --> cdnUpstream["10.1.2.1,10.1.2.2"]
  pingap -- proxy:/* --> upstream["10.1.3.1,10.1.3.2"]

主な機能

  • 🚀 高性能と信頼性

    • メモリ安全性と最高レベルのパフォーマンスを実現するRustで構築。
    • 実戦で検証された非同期ネットワーキングライブラリであるCloudflare Pingoraを搭載。
    • HTTP/1.1、HTTP/2、およびgRPC-webプロキシをサポート。
  • 🔧 動的かつ使いやすい

    • ホットリロードによるダウンタイムゼロの設定変更。
    • シンプルで人間が読みやすいTOML設定ファイル。
    • 直感的でリアルタイムな管理を実現するフル機能のWeb UI。
    • 設定バックエンドとしてファイルとetcdの両方をサポート。
    • 設定履歴の記録をサポートし、ワンクリックで履歴バージョンに復元可能。
  • 🧩 強力な拡張性

    • 一般的なゲートウェイタスクを処理するための豊富なプラグインシステム。
    • ホスト、パス、および正規表現マッチングによる高度なルーティング。
    • 静的リスト、DNS、またはDockerラベルによる組み込みのサービスディスカバリ。
    • Let's Encryptによる自動HTTPS(HTTP-01およびDNS-01チャレンジの両方をサポート)。
  • 📊 最新の可観測性

    • モニタリングのためのネイティブPrometheusメトリクス(プル&プッシュモード)。
    • 分散トレーシングのための統合OpenTelemetryサポート。
    • 30以上の変数を持つ高度にカスタマイズ可能なアクセスログ。
    • アップストリーム接続時間、処理時間などを含む詳細なパフォーマンスメトリクス。

🚀 はじめに

Pingapを始める最も簡単な方法は、Docker Composeを使用することです。

  1. docker-compose.ymlファイルを作成します:
root@kitploit:~
# docker-compose.yml
version: '3.8'

services:
  pingap:
    image: vicanso/pingap:latest # 本番環境では、vicanso/pingap:0.12.1-fullのような特定のバージョンを使用してください
    container_name: pingap-instance
    restart: always
    ports:
      - "80:80"
      - "443:443"
    volumes:
      # すべての設定とデータを永続化するためにローカルディレクトリをマウント
      - ./pingap_data:/opt/pingap
    environment:
      # 環境変数を使用して設定
      - PINGAP_CONF=/opt/pingap/conf
      - PINGAP_ADMIN_ADDR=0.0.0.0:80/pingap
      - PINGAP_ADMIN_USER=pingap
      - PINGAP_ADMIN_PASSWORD=<YourSecurePassword> # これを変更してください!
    command:
      # pingapを起動し、ホットリロードを有効化
      - pingap
      - --autoreload
  1. データディレクトリを作成して実行します:
root@kitploit:~
mkdir pingap_data
docker-compose up -d
  1. 管理UIにアクセスします:

Pingapインスタンスが実行されました!設定した認証情報を使用して、http://localhost/pingap でWeb管理インターフェースにアクセスできます。

curlによるバイナリのインストール

LinuxおよびmacOSでは、以下の1つのコマンドで最新のプレビルドバイナリを /usr/local/bin/pingap にインストールできます:

root@kitploit:~
curl -sSL https://raw.githubusercontent.com/vicanso/pingap/main/install.sh | sh

オプションの環境変数:

  • PINGAP_FULL=1 — -fullビルドをインストール(すべてのオプション機能を有効化)
  • PINGAP_LIBC=gnu — Linuxで、デフォルトのmusl静的ビルドの代わりにglibcビルドを使用
  • PINGAP_TLS=rustls — Linuxで、-rustls-fullビルドをインストール(rustls TLSバックエンド、すべてのオプション機能、OpenSSLなし); TLSバックエンドを参照
root@kitploit:~
# フル機能ビルド
curl -sSL https://raw.githubusercontent.com/vicanso/pingap/main/install.sh | PINGAP_FULL=1 sh

サポート対象ターゲット: Linux x86_64/arm64、Darwin x86_64/arm64。利用可能なすべてのアセットについては、リリースページを参照してください。

バイナリからの実行を含むより詳細な手順については、ドキュメントを参照してください。

設定ファイルなしでプロキシを開始

1つのコマンドで、ドメインをhttpsで提供し、バックエンドに転送できます:

root@kitploit:~
# let's encryptから証明書を取得
pingap --domain=pingap.io --upstream=192.168.1.1:3000

# または独自の証明書を使用
pingap --domain=pingap.io --upstream=192.168.1.1:3000 --cert=/etc/ssl/pingap.io

--certがない場合、PingapはHTTP-01チャレンジを通じてLet's Encryptに証明書を要求するため、pingap.ioはこのホストに解決され、ポート80がインターネットから到達可能である必要があります。発行された証明書は ~/.pingap/acme/<domains>.toml に保存され、再起動時に再利用されます — 発行にはレート制限があるため、削除しないでください。その他はすべてコマンドラインから取得されます: --upstream を変更すると、証明書に触れることなく次回起動時に反映されます。

--cert は証明書自体またはそれを保持するディレクトリを受け入れます — 一般的な fullchain.pem / privkey.pem、cert.pem / key.pem、および tls.crt / tls.key のレイアウトは自動的に検出され、その他の場合は --key を使用します。リスナーは、証明書がある場合はデフォルトで 0.0.0.0:443、証明書もドメインもない場合は 0.0.0.0:80 になり、--addr で上書きできます。--upstream はカンマ区切りのバックエンドリストを受け取り、--domain はカンマ区切りのホストリストを受け取ります(省略すると、すべてのホストをプレーンなhttpで提供します)。リストにないホストへのリクエストは404で応答されます。

設定は起動のたびに生成されるため、管理UIから編集することはできません: 単一サーバーを超えるものには --conf を使用してください。これはこれらのフラグと組み合わせることはできません。

動的設定

Pingapは、ダウンタイムなしで設定変更に適応するように設計されています。

ホットリロード (--autoreload): アップストリーム、ロケーション、プラグインの更新などほとんどの変更に対して、Pingapは再起動なしで10秒以内に新しい設定を適用します。これはコンテナ化された環境で推奨されるモードです。

グレースフル再起動 (-a または --autorestart): サーバーのリッスンポートの変更などの基本的な変更に対して、このモードは完全なダウンタイムゼロの再起動を実行し、リクエストがドロップされないことを保証します。

引き継ぎはタイマーではなく準備完了ベースで行われます: 後継プロセスは -d -u で起動され、アップグレードソケットの隣のunixソケットを介してリスナーを引き継ぐ準備ができた瞬間に報告し、その後にのみ実行中のプロセスが自身にSIGQUITを送信します。後継プロセスが終了した場合、そのデーモンが停止した場合、または basic.restart_ready_timeout(デフォルト1m)が先に経過した場合、再起動は中止され、実行中のプロセスはサービスを継続します。

🔧 開発

root@kitploit:~
make dev

Web管理が必要な場合は、nodejsをインストールしてWebアセットをビルドする必要があります。

root@kitploit:~
# 管理Webアセットを生成
cd web
npm i 
cd ..
make build-web

TLSバックエンド

デフォルトのビルドは、opensslクレートによってソースからコンパイルされたOpenSSLでTLSを終端します。代わりにrustlsでビルドする場合、OpenSSLのソースビルドが不要になります(Cコンパイラは依然として必要です: rustlsの暗号プロバイダであるringとaws-lc-rsにはCおよびアセンブリが含まれています):

root@kitploit:~
cargo build --release --no-default-features --features tls-rustls
# オプション機能も含める場合
cargo build --release --no-default-features --features tls-rustls,full

rustlsビルドは、サーバーごとの tls_min_version、tls_max_version、tls_cipher_list、および tls_ciphersuites 設定を無視し、それらが設定されている場合は警告をログに記録します: 常にrustlsのデフォルトの暗号スイートでTLS 1.2および1.3を提供します。動的SNI証明書、自己署名CA発行、ACME、アップストリームの ca オプションを含むその他すべては同じように動作します。アップストリームを検証する際に知っておくべき違いが1つあります: rustls(webpki)は CA:TRUE を持つサーバー証明書を拒否しますが、OpenSSLはこれを受け入れます。そのため、簡単な openssl req -x509 自己署名証明書を使用するバックエンドは、アップストリームの ca オプションがそれを信頼できるようになる前に、CAによって署名された適切なリーフ証明書(またはCAフラグのない自己署名リーフ)が必要です。起動ログは、バイナリがどのバックエンドでビルドされたかを報告します。

📝 設定

root@kitploit:~
server "test" {
  addr = "127.0.0.1:6118"

  location "github-api" {
    path = "/api"
    proxy_set_headers = ["Host:api.github.com"]
    rewrite = "^/api/(?<path>.+)$ /$1"

    upstream "api" {
      addrs     = ["api.github.com:443"]
      discovery = "dns"
      sni       = "api.github.com"
    }
  }

  location "static" {
    plugin "staticServe" {
      category = "directory"
      path     = "~/Downloads"
      step     = "request"
    }
  }
}
root@kitploit:~
[upstreams.api]
addrs = ["api.github.com:443"]
discovery = "dns"
sni = "api.github.com"

[plugins.staticServe]
category = "directory"
path = "~/Downloads"
step = "request"

[locations.github-api]
upstream = "api"
path = "/api"
proxy_set_headers = ["Host:api.github.com"]
rewrite = "^/api/(?<path>.+)$ /$1"

[locations.static]
plugins = ["staticServe"]

[servers.test]
addr = "127.0.0.1:6118"
locations = ["github-api", "static"]

関連する手順はこちらで確認できます: https://pingap.io/crates/config。

🔄 プロキシステップ

root@kitploit:~
graph TD;
  server["HTTP Server"];
  locationA["Location A"];
  locationB["Location B"];
  locationPluginListA["Proxy Plugin List A"];
  locationPluginListB["Proxy Plugin List B"];
  upstreamA1["Upstream A1"];
  upstreamA2["Upstream A2"];
  upstreamB1["Upstream B1"];
  upstreamB2["Upstream B2"];
  locationResponsePluginListA["Response Plugin List A"];
  locationResponsePluginListB["Response Plugin List B"];

  start("New Request") --> server

  server -- "host:HostA, Path:/api/*" --> locationA

  server -- "Path:/rest/*"--> locationB

  locationA -- "Exec Proxy Plugins" --> locationPluginListA

  locationB -- "Exec Proxy Plugins" --> locationPluginListB

  locationPluginListA -- "proxy pass: 10.0.0.1:8001" --> upstreamA1

  locationPluginListA -- "proxy pass: 10.0.0.2:8001" --> upstreamA2

  locationPluginListA -- "done" --> response

  locationPluginListB -- "proxy pass: 10.0.0.1:8002" --> upstreamB1

  locationPluginListB -- "proxy pass: 10.0.0.2:8002" --> upstreamB2

  locationPluginListB -- "done" --> response

  upstreamA1 -- "Exec Response Plugins" --> locationResponsePluginListA
  upstreamA2 -- "Exec Response Plugins" --> locationResponsePluginListA

  upstreamB1 -- "Exec Response Plugins" --> locationResponsePluginListB
  upstreamB2 -- "Exec Response Plugins" --> locationResponsePluginListB

  locationResponsePluginListA --> response
  locationResponsePluginListB --> response

  response["HTTP Response"] --> stop("Logging");

📊 パフォーマンス

CPU: M4 Pro, Thread: 1

Ping アクセスログなし

root@kitploit:~
wrk 'http://127.0.0.1:6118/ping' --latency

Running 10s test @ http://127.0.0.1:6118/ping
  2 threads and 10 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    66.41us   23.67us   1.11ms   76.54%
    Req/Sec    73.99k     2.88k   79.77k    68.81%
  Latency Distribution
     50%   67.00us
     75%   80.00us
     90%   91.00us
     99%  116.00us
  1487330 requests in 10.10s, 194.32MB read
Requests/sec: 147260.15
Transfer/sec:     19.24MB

📦 Rustバージョン

現在のMSRVは1.96です

📄 ライセンス

このプロジェクトはApache License, Version 2.0の下でライセンスされています。

ツールをダウンロード