3x-ui/web/job/check_client_ip_job.go

322 lines
7.3 KiB
Go
Raw Normal View History

2023-02-28 19:54:29 +00:00
package job
import (
"bufio"
2023-04-13 19:37:13 +00:00
"encoding/json"
"io"
"log"
2023-04-13 19:37:13 +00:00
"os"
2023-09-01 09:53:50 +00:00
"os/exec"
2023-04-13 19:37:13 +00:00
"regexp"
2025-09-10 19:12:37 +00:00
"runtime"
"sort"
"time"
2025-09-19 08:05:43 +00:00
"github.com/mhsanaei/3x-ui/v2/database"
"github.com/mhsanaei/3x-ui/v2/database/model"
"github.com/mhsanaei/3x-ui/v2/logger"
"github.com/mhsanaei/3x-ui/v2/xray"
2023-02-28 19:54:29 +00:00
)
2025-09-20 07:35:50 +00:00
// CheckClientIpJob monitors client IP addresses from access logs and manages IP blocking based on configured limits.
type CheckClientIpJob struct {
lastClear int64
disAllowedIps []string
}
2023-04-13 19:37:13 +00:00
2023-02-28 19:54:29 +00:00
var job *CheckClientIpJob
2025-09-20 07:35:50 +00:00
// NewCheckClientIpJob creates a new client IP monitoring job instance.
2023-02-28 19:54:29 +00:00
func NewCheckClientIpJob() *CheckClientIpJob {
job = new(CheckClientIpJob)
2023-02-28 19:54:29 +00:00
return job
}
func (j *CheckClientIpJob) Run() {
if j.lastClear == 0 {
j.lastClear = time.Now().Unix()
}
shouldClearAccessLog := false
iplimitActive := j.hasLimitIp()
2024-10-28 19:13:42 +00:00
f2bInstalled := j.checkFail2BanInstalled()
isAccessLogAvailable := j.checkAccessLogAvailable(iplimitActive)
2025-09-11 09:05:06 +00:00
if isAccessLogAvailable {
2025-09-10 19:12:37 +00:00
if runtime.GOOS == "windows" {
2025-09-11 09:05:06 +00:00
if iplimitActive {
2025-09-10 19:12:37 +00:00
shouldClearAccessLog = j.processLogFile()
}
2024-10-28 19:13:42 +00:00
} else {
2025-09-11 09:05:06 +00:00
if iplimitActive {
if f2bInstalled {
shouldClearAccessLog = j.processLogFile()
} else {
if !f2bInstalled {
logger.Warning("[LimitIP] Fail2Ban is not installed, Please install Fail2Ban from the x-ui bash menu.")
}
2025-09-10 19:12:37 +00:00
}
2024-10-28 19:13:42 +00:00
}
}
}
if shouldClearAccessLog || (isAccessLogAvailable && time.Now().Unix()-j.lastClear > 3600) {
j.clearAccessLog()
}
}
func (j *CheckClientIpJob) clearAccessLog() {
logAccessP, err := os.OpenFile(xray.GetAccessPersistentLogPath(), os.O_CREATE|os.O_APPEND|os.O_WRONLY, 0o644)
j.checkError(err)
2025-08-17 11:37:49 +00:00
defer logAccessP.Close()
accessLogPath, err := xray.GetAccessLogPath()
j.checkError(err)
file, err := os.Open(accessLogPath)
j.checkError(err)
2025-08-17 11:37:49 +00:00
defer file.Close()
_, err = io.Copy(logAccessP, file)
j.checkError(err)
err = os.Truncate(accessLogPath, 0)
j.checkError(err)
2025-08-17 11:37:49 +00:00
j.lastClear = time.Now().Unix()
2023-02-28 19:54:29 +00:00
}
func (j *CheckClientIpJob) hasLimitIp() bool {
db := database.GetDB()
var inbounds []*model.Inbound
err := db.Model(model.Inbound{}).Find(&inbounds).Error
if err != nil {
return false
}
for _, inbound := range inbounds {
if inbound.Settings == "" {
continue
}
settings := map[string][]model.Client{}
json.Unmarshal([]byte(inbound.Settings), &settings)
clients := settings["clients"]
for _, client := range clients {
limitIp := client.LimitIP
if limitIp > 0 {
return true
}
}
}
return false
}
func (j *CheckClientIpJob) processLogFile() bool {
ipRegex := regexp.MustCompile(`from (?:tcp:|udp:)?\[?([0-9a-fA-F\.:]+)\]?:\d+ accepted`)
2024-10-28 19:13:42 +00:00
emailRegex := regexp.MustCompile(`email: (.+)$`)
accessLogPath, _ := xray.GetAccessLogPath()
file, _ := os.Open(accessLogPath)
defer file.Close()
# Pull Request: Connection Reporting System & Improvements for Restricted Networks ## Description This PR introduces a comprehensive **Connection Reporting System** designed to improve the reliability and monitoring of connections, specifically tailored for environments with restricted internet access (e.g., active censorship, GFW). ### Key Changes 1. **New Reporting API (`/report`)**: * Added `ReportController` and `ReportService` to handle incoming connection reports. * Endpoint receives data such as `Latency`, `Success` status, `Protocol`, and Client Interface details. * Data is persisted to the database via the new `ConnectionReport` model. 2. **Subscription Link Updates**: * Modified `subService` to append a `reportUrl` parameter to generated subscription links (VLESS, VMess, etc.). * This allows compatible clients to automatically discover the reporting endpoint and send feedback. 3. **Database Integration**: * Added `ConnectionReport` schema to `database/model` and registered it in `database/db.go` for auto-migration. ## Why is this helpful for Restricted Internet Locations? In regions with heavy internet censorship, connection stability is volatile. * **Dynamic Reporting Endpoint**: The `reportUrl` parameter embedded in the subscription link explicitly tells the client *where* to send connection data. * **Bypassing Blocking**: By decoupling the reporting URL from the node address, clients can ensure diagnostic data reaches the panel even if specific node IPs are being interfered with (assuming the panel itself is reachable). * **Real-time Network Intelligence**: This mechanism enables the panel to aggregate "ground truth" data from clients inside the restricted network (e.g., latency, accessibility of specific protocols), allowing admins to react faster to blocking events. * **Protocol Performance Tracking**: Allows comparison of different protocols (Reality vs. VLESS+TLS vs. Trojan) based on real-world latency and success rates from actual users. * **Rapid Troubleshooting**: Administrators can see connection quality trends and rotate IPs/domains proactively when success rates drop, minimizing downtime for users. ## Technical Details * **API Endpoint**: `POST /report` * **Payload Format**: JSON containing `SystemInfo` (Interface), `ConnectionQuality` (Latency, Success), and `ProtocolInfo`. * **Security**: Reports are tied to valid client request contexts (implementation detail: ensure endpoint is rate-limited or authenticated if necessary, though currently designed for open reporting from valid sub links). ## How to Test 1. Update the panel. 2. Generate a subscription link. 3. Observe the `reportUrl` parameter in the link. 4. Simulate a client POST to the report URL and verify the entry in the `ConnectionReports` table.
2026-02-04 10:00:00 +00:00
inboundClientIps := make(map[string]map[string]struct{}, 100)
scanner := bufio.NewScanner(file)
for scanner.Scan() {
line := scanner.Text()
2023-02-28 19:54:29 +00:00
2024-10-28 19:13:42 +00:00
ipMatches := ipRegex.FindStringSubmatch(line)
if len(ipMatches) < 2 {
continue
}
2023-02-28 19:54:29 +00:00
2024-10-28 19:13:42 +00:00
ip := ipMatches[1]
2023-02-28 19:54:29 +00:00
2024-10-28 19:13:42 +00:00
if ip == "127.0.0.1" || ip == "::1" {
continue
}
2023-04-13 19:37:13 +00:00
2024-10-28 19:13:42 +00:00
emailMatches := emailRegex.FindStringSubmatch(line)
if len(emailMatches) < 2 {
continue
2023-02-28 19:54:29 +00:00
}
2024-10-28 19:13:42 +00:00
email := emailMatches[1]
2024-10-28 19:13:42 +00:00
if _, exists := inboundClientIps[email]; !exists {
# Pull Request: Connection Reporting System & Improvements for Restricted Networks ## Description This PR introduces a comprehensive **Connection Reporting System** designed to improve the reliability and monitoring of connections, specifically tailored for environments with restricted internet access (e.g., active censorship, GFW). ### Key Changes 1. **New Reporting API (`/report`)**: * Added `ReportController` and `ReportService` to handle incoming connection reports. * Endpoint receives data such as `Latency`, `Success` status, `Protocol`, and Client Interface details. * Data is persisted to the database via the new `ConnectionReport` model. 2. **Subscription Link Updates**: * Modified `subService` to append a `reportUrl` parameter to generated subscription links (VLESS, VMess, etc.). * This allows compatible clients to automatically discover the reporting endpoint and send feedback. 3. **Database Integration**: * Added `ConnectionReport` schema to `database/model` and registered it in `database/db.go` for auto-migration. ## Why is this helpful for Restricted Internet Locations? In regions with heavy internet censorship, connection stability is volatile. * **Dynamic Reporting Endpoint**: The `reportUrl` parameter embedded in the subscription link explicitly tells the client *where* to send connection data. * **Bypassing Blocking**: By decoupling the reporting URL from the node address, clients can ensure diagnostic data reaches the panel even if specific node IPs are being interfered with (assuming the panel itself is reachable). * **Real-time Network Intelligence**: This mechanism enables the panel to aggregate "ground truth" data from clients inside the restricted network (e.g., latency, accessibility of specific protocols), allowing admins to react faster to blocking events. * **Protocol Performance Tracking**: Allows comparison of different protocols (Reality vs. VLESS+TLS vs. Trojan) based on real-world latency and success rates from actual users. * **Rapid Troubleshooting**: Administrators can see connection quality trends and rotate IPs/domains proactively when success rates drop, minimizing downtime for users. ## Technical Details * **API Endpoint**: `POST /report` * **Payload Format**: JSON containing `SystemInfo` (Interface), `ConnectionQuality` (Latency, Success), and `ProtocolInfo`. * **Security**: Reports are tied to valid client request contexts (implementation detail: ensure endpoint is rate-limited or authenticated if necessary, though currently designed for open reporting from valid sub links). ## How to Test 1. Update the panel. 2. Generate a subscription link. 3. Observe the `reportUrl` parameter in the link. 4. Simulate a client POST to the report URL and verify the entry in the `ConnectionReports` table.
2026-02-04 10:00:00 +00:00
inboundClientIps[email] = make(map[string]struct{})
2024-10-28 19:13:42 +00:00
}
# Pull Request: Connection Reporting System & Improvements for Restricted Networks ## Description This PR introduces a comprehensive **Connection Reporting System** designed to improve the reliability and monitoring of connections, specifically tailored for environments with restricted internet access (e.g., active censorship, GFW). ### Key Changes 1. **New Reporting API (`/report`)**: * Added `ReportController` and `ReportService` to handle incoming connection reports. * Endpoint receives data such as `Latency`, `Success` status, `Protocol`, and Client Interface details. * Data is persisted to the database via the new `ConnectionReport` model. 2. **Subscription Link Updates**: * Modified `subService` to append a `reportUrl` parameter to generated subscription links (VLESS, VMess, etc.). * This allows compatible clients to automatically discover the reporting endpoint and send feedback. 3. **Database Integration**: * Added `ConnectionReport` schema to `database/model` and registered it in `database/db.go` for auto-migration. ## Why is this helpful for Restricted Internet Locations? In regions with heavy internet censorship, connection stability is volatile. * **Dynamic Reporting Endpoint**: The `reportUrl` parameter embedded in the subscription link explicitly tells the client *where* to send connection data. * **Bypassing Blocking**: By decoupling the reporting URL from the node address, clients can ensure diagnostic data reaches the panel even if specific node IPs are being interfered with (assuming the panel itself is reachable). * **Real-time Network Intelligence**: This mechanism enables the panel to aggregate "ground truth" data from clients inside the restricted network (e.g., latency, accessibility of specific protocols), allowing admins to react faster to blocking events. * **Protocol Performance Tracking**: Allows comparison of different protocols (Reality vs. VLESS+TLS vs. Trojan) based on real-world latency and success rates from actual users. * **Rapid Troubleshooting**: Administrators can see connection quality trends and rotate IPs/domains proactively when success rates drop, minimizing downtime for users. ## Technical Details * **API Endpoint**: `POST /report` * **Payload Format**: JSON containing `SystemInfo` (Interface), `ConnectionQuality` (Latency, Success), and `ProtocolInfo`. * **Security**: Reports are tied to valid client request contexts (implementation detail: ensure endpoint is rate-limited or authenticated if necessary, though currently designed for open reporting from valid sub links). ## How to Test 1. Update the panel. 2. Generate a subscription link. 3. Observe the `reportUrl` parameter in the link. 4. Simulate a client POST to the report URL and verify the entry in the `ConnectionReports` table.
2026-02-04 10:00:00 +00:00
inboundClientIps[email][ip] = struct{}{}
2024-10-28 19:13:42 +00:00
}
shouldCleanLog := false
# Pull Request: Connection Reporting System & Improvements for Restricted Networks ## Description This PR introduces a comprehensive **Connection Reporting System** designed to improve the reliability and monitoring of connections, specifically tailored for environments with restricted internet access (e.g., active censorship, GFW). ### Key Changes 1. **New Reporting API (`/report`)**: * Added `ReportController` and `ReportService` to handle incoming connection reports. * Endpoint receives data such as `Latency`, `Success` status, `Protocol`, and Client Interface details. * Data is persisted to the database via the new `ConnectionReport` model. 2. **Subscription Link Updates**: * Modified `subService` to append a `reportUrl` parameter to generated subscription links (VLESS, VMess, etc.). * This allows compatible clients to automatically discover the reporting endpoint and send feedback. 3. **Database Integration**: * Added `ConnectionReport` schema to `database/model` and registered it in `database/db.go` for auto-migration. ## Why is this helpful for Restricted Internet Locations? In regions with heavy internet censorship, connection stability is volatile. * **Dynamic Reporting Endpoint**: The `reportUrl` parameter embedded in the subscription link explicitly tells the client *where* to send connection data. * **Bypassing Blocking**: By decoupling the reporting URL from the node address, clients can ensure diagnostic data reaches the panel even if specific node IPs are being interfered with (assuming the panel itself is reachable). * **Real-time Network Intelligence**: This mechanism enables the panel to aggregate "ground truth" data from clients inside the restricted network (e.g., latency, accessibility of specific protocols), allowing admins to react faster to blocking events. * **Protocol Performance Tracking**: Allows comparison of different protocols (Reality vs. VLESS+TLS vs. Trojan) based on real-world latency and success rates from actual users. * **Rapid Troubleshooting**: Administrators can see connection quality trends and rotate IPs/domains proactively when success rates drop, minimizing downtime for users. ## Technical Details * **API Endpoint**: `POST /report` * **Payload Format**: JSON containing `SystemInfo` (Interface), `ConnectionQuality` (Latency, Success), and `ProtocolInfo`. * **Security**: Reports are tied to valid client request contexts (implementation detail: ensure endpoint is rate-limited or authenticated if necessary, though currently designed for open reporting from valid sub links). ## How to Test 1. Update the panel. 2. Generate a subscription link. 3. Observe the `reportUrl` parameter in the link. 4. Simulate a client POST to the report URL and verify the entry in the `ConnectionReports` table.
2026-02-04 10:00:00 +00:00
for email, uniqueIps := range inboundClientIps {
2023-02-28 19:54:29 +00:00
# Pull Request: Connection Reporting System & Improvements for Restricted Networks ## Description This PR introduces a comprehensive **Connection Reporting System** designed to improve the reliability and monitoring of connections, specifically tailored for environments with restricted internet access (e.g., active censorship, GFW). ### Key Changes 1. **New Reporting API (`/report`)**: * Added `ReportController` and `ReportService` to handle incoming connection reports. * Endpoint receives data such as `Latency`, `Success` status, `Protocol`, and Client Interface details. * Data is persisted to the database via the new `ConnectionReport` model. 2. **Subscription Link Updates**: * Modified `subService` to append a `reportUrl` parameter to generated subscription links (VLESS, VMess, etc.). * This allows compatible clients to automatically discover the reporting endpoint and send feedback. 3. **Database Integration**: * Added `ConnectionReport` schema to `database/model` and registered it in `database/db.go` for auto-migration. ## Why is this helpful for Restricted Internet Locations? In regions with heavy internet censorship, connection stability is volatile. * **Dynamic Reporting Endpoint**: The `reportUrl` parameter embedded in the subscription link explicitly tells the client *where* to send connection data. * **Bypassing Blocking**: By decoupling the reporting URL from the node address, clients can ensure diagnostic data reaches the panel even if specific node IPs are being interfered with (assuming the panel itself is reachable). * **Real-time Network Intelligence**: This mechanism enables the panel to aggregate "ground truth" data from clients inside the restricted network (e.g., latency, accessibility of specific protocols), allowing admins to react faster to blocking events. * **Protocol Performance Tracking**: Allows comparison of different protocols (Reality vs. VLESS+TLS vs. Trojan) based on real-world latency and success rates from actual users. * **Rapid Troubleshooting**: Administrators can see connection quality trends and rotate IPs/domains proactively when success rates drop, minimizing downtime for users. ## Technical Details * **API Endpoint**: `POST /report` * **Payload Format**: JSON containing `SystemInfo` (Interface), `ConnectionQuality` (Latency, Success), and `ProtocolInfo`. * **Security**: Reports are tied to valid client request contexts (implementation detail: ensure endpoint is rate-limited or authenticated if necessary, though currently designed for open reporting from valid sub links). ## How to Test 1. Update the panel. 2. Generate a subscription link. 3. Observe the `reportUrl` parameter in the link. 4. Simulate a client POST to the report URL and verify the entry in the `ConnectionReports` table.
2026-02-04 10:00:00 +00:00
ips := make([]string, 0, len(uniqueIps))
for ip := range uniqueIps {
ips = append(ips, ip)
2024-10-28 19:13:42 +00:00
}
# Pull Request: Connection Reporting System & Improvements for Restricted Networks ## Description This PR introduces a comprehensive **Connection Reporting System** designed to improve the reliability and monitoring of connections, specifically tailored for environments with restricted internet access (e.g., active censorship, GFW). ### Key Changes 1. **New Reporting API (`/report`)**: * Added `ReportController` and `ReportService` to handle incoming connection reports. * Endpoint receives data such as `Latency`, `Success` status, `Protocol`, and Client Interface details. * Data is persisted to the database via the new `ConnectionReport` model. 2. **Subscription Link Updates**: * Modified `subService` to append a `reportUrl` parameter to generated subscription links (VLESS, VMess, etc.). * This allows compatible clients to automatically discover the reporting endpoint and send feedback. 3. **Database Integration**: * Added `ConnectionReport` schema to `database/model` and registered it in `database/db.go` for auto-migration. ## Why is this helpful for Restricted Internet Locations? In regions with heavy internet censorship, connection stability is volatile. * **Dynamic Reporting Endpoint**: The `reportUrl` parameter embedded in the subscription link explicitly tells the client *where* to send connection data. * **Bypassing Blocking**: By decoupling the reporting URL from the node address, clients can ensure diagnostic data reaches the panel even if specific node IPs are being interfered with (assuming the panel itself is reachable). * **Real-time Network Intelligence**: This mechanism enables the panel to aggregate "ground truth" data from clients inside the restricted network (e.g., latency, accessibility of specific protocols), allowing admins to react faster to blocking events. * **Protocol Performance Tracking**: Allows comparison of different protocols (Reality vs. VLESS+TLS vs. Trojan) based on real-world latency and success rates from actual users. * **Rapid Troubleshooting**: Administrators can see connection quality trends and rotate IPs/domains proactively when success rates drop, minimizing downtime for users. ## Technical Details * **API Endpoint**: `POST /report` * **Payload Format**: JSON containing `SystemInfo` (Interface), `ConnectionQuality` (Latency, Success), and `ProtocolInfo`. * **Security**: Reports are tied to valid client request contexts (implementation detail: ensure endpoint is rate-limited or authenticated if necessary, though currently designed for open reporting from valid sub links). ## How to Test 1. Update the panel. 2. Generate a subscription link. 3. Observe the `reportUrl` parameter in the link. 4. Simulate a client POST to the report URL and verify the entry in the `ConnectionReports` table.
2026-02-04 10:00:00 +00:00
sort.Strings(ips)
2024-10-28 19:13:42 +00:00
2024-12-16 13:26:47 +00:00
clientIpsRecord, err := j.getInboundClientIps(email)
2023-04-13 19:37:13 +00:00
if err != nil {
# Pull Request: Connection Reporting System & Improvements for Restricted Networks ## Description This PR introduces a comprehensive **Connection Reporting System** designed to improve the reliability and monitoring of connections, specifically tailored for environments with restricted internet access (e.g., active censorship, GFW). ### Key Changes 1. **New Reporting API (`/report`)**: * Added `ReportController` and `ReportService` to handle incoming connection reports. * Endpoint receives data such as `Latency`, `Success` status, `Protocol`, and Client Interface details. * Data is persisted to the database via the new `ConnectionReport` model. 2. **Subscription Link Updates**: * Modified `subService` to append a `reportUrl` parameter to generated subscription links (VLESS, VMess, etc.). * This allows compatible clients to automatically discover the reporting endpoint and send feedback. 3. **Database Integration**: * Added `ConnectionReport` schema to `database/model` and registered it in `database/db.go` for auto-migration. ## Why is this helpful for Restricted Internet Locations? In regions with heavy internet censorship, connection stability is volatile. * **Dynamic Reporting Endpoint**: The `reportUrl` parameter embedded in the subscription link explicitly tells the client *where* to send connection data. * **Bypassing Blocking**: By decoupling the reporting URL from the node address, clients can ensure diagnostic data reaches the panel even if specific node IPs are being interfered with (assuming the panel itself is reachable). * **Real-time Network Intelligence**: This mechanism enables the panel to aggregate "ground truth" data from clients inside the restricted network (e.g., latency, accessibility of specific protocols), allowing admins to react faster to blocking events. * **Protocol Performance Tracking**: Allows comparison of different protocols (Reality vs. VLESS+TLS vs. Trojan) based on real-world latency and success rates from actual users. * **Rapid Troubleshooting**: Administrators can see connection quality trends and rotate IPs/domains proactively when success rates drop, minimizing downtime for users. ## Technical Details * **API Endpoint**: `POST /report` * **Payload Format**: JSON containing `SystemInfo` (Interface), `ConnectionQuality` (Latency, Success), and `ProtocolInfo`. * **Security**: Reports are tied to valid client request contexts (implementation detail: ensure endpoint is rate-limited or authenticated if necessary, though currently designed for open reporting from valid sub links). ## How to Test 1. Update the panel. 2. Generate a subscription link. 3. Observe the `reportUrl` parameter in the link. 4. Simulate a client POST to the report URL and verify the entry in the `ConnectionReports` table.
2026-02-04 10:00:00 +00:00
j.addInboundClientIps(email, ips)
2024-10-28 19:13:42 +00:00
continue
2023-02-28 19:54:29 +00:00
}
2024-10-28 19:13:42 +00:00
# Pull Request: Connection Reporting System & Improvements for Restricted Networks ## Description This PR introduces a comprehensive **Connection Reporting System** designed to improve the reliability and monitoring of connections, specifically tailored for environments with restricted internet access (e.g., active censorship, GFW). ### Key Changes 1. **New Reporting API (`/report`)**: * Added `ReportController` and `ReportService` to handle incoming connection reports. * Endpoint receives data such as `Latency`, `Success` status, `Protocol`, and Client Interface details. * Data is persisted to the database via the new `ConnectionReport` model. 2. **Subscription Link Updates**: * Modified `subService` to append a `reportUrl` parameter to generated subscription links (VLESS, VMess, etc.). * This allows compatible clients to automatically discover the reporting endpoint and send feedback. 3. **Database Integration**: * Added `ConnectionReport` schema to `database/model` and registered it in `database/db.go` for auto-migration. ## Why is this helpful for Restricted Internet Locations? In regions with heavy internet censorship, connection stability is volatile. * **Dynamic Reporting Endpoint**: The `reportUrl` parameter embedded in the subscription link explicitly tells the client *where* to send connection data. * **Bypassing Blocking**: By decoupling the reporting URL from the node address, clients can ensure diagnostic data reaches the panel even if specific node IPs are being interfered with (assuming the panel itself is reachable). * **Real-time Network Intelligence**: This mechanism enables the panel to aggregate "ground truth" data from clients inside the restricted network (e.g., latency, accessibility of specific protocols), allowing admins to react faster to blocking events. * **Protocol Performance Tracking**: Allows comparison of different protocols (Reality vs. VLESS+TLS vs. Trojan) based on real-world latency and success rates from actual users. * **Rapid Troubleshooting**: Administrators can see connection quality trends and rotate IPs/domains proactively when success rates drop, minimizing downtime for users. ## Technical Details * **API Endpoint**: `POST /report` * **Payload Format**: JSON containing `SystemInfo` (Interface), `ConnectionQuality` (Latency, Success), and `ProtocolInfo`. * **Security**: Reports are tied to valid client request contexts (implementation detail: ensure endpoint is rate-limited or authenticated if necessary, though currently designed for open reporting from valid sub links). ## How to Test 1. Update the panel. 2. Generate a subscription link. 3. Observe the `reportUrl` parameter in the link. 4. Simulate a client POST to the report URL and verify the entry in the `ConnectionReports` table.
2026-02-04 10:00:00 +00:00
shouldCleanLog = j.updateInboundClientIps(clientIpsRecord, email, ips) || shouldCleanLog
2023-04-13 19:37:13 +00:00
}
return shouldCleanLog
2023-02-28 19:54:29 +00:00
}
2024-10-28 19:13:42 +00:00
func (j *CheckClientIpJob) checkFail2BanInstalled() bool {
cmd := "fail2ban-client"
args := []string{"-h"}
err := exec.Command(cmd, args...).Run()
2024-10-28 19:13:42 +00:00
return err == nil
}
func (j *CheckClientIpJob) checkAccessLogAvailable(iplimitActive bool) bool {
accessLogPath, err := xray.GetAccessLogPath()
if err != nil {
return false
}
if accessLogPath == "none" || accessLogPath == "" {
if iplimitActive {
2024-09-24 11:24:10 +00:00
logger.Warning("[LimitIP] Access log path is not set, Please configure the access log path in Xray configs.")
}
return false
}
return true
}
func (j *CheckClientIpJob) checkError(e error) {
2023-04-13 19:37:13 +00:00
if e != nil {
2023-02-28 19:54:29 +00:00
logger.Warning("client ip job err:", e)
}
}
func (j *CheckClientIpJob) getInboundClientIps(clientEmail string) (*model.InboundClientIps, error) {
2023-02-28 19:54:29 +00:00
db := database.GetDB()
InboundClientIps := &model.InboundClientIps{}
err := db.Model(model.InboundClientIps{}).Where("client_email = ?", clientEmail).First(InboundClientIps).Error
if err != nil {
return nil, err
}
return InboundClientIps, nil
}
# Pull Request: Connection Reporting System & Improvements for Restricted Networks ## Description This PR introduces a comprehensive **Connection Reporting System** designed to improve the reliability and monitoring of connections, specifically tailored for environments with restricted internet access (e.g., active censorship, GFW). ### Key Changes 1. **New Reporting API (`/report`)**: * Added `ReportController` and `ReportService` to handle incoming connection reports. * Endpoint receives data such as `Latency`, `Success` status, `Protocol`, and Client Interface details. * Data is persisted to the database via the new `ConnectionReport` model. 2. **Subscription Link Updates**: * Modified `subService` to append a `reportUrl` parameter to generated subscription links (VLESS, VMess, etc.). * This allows compatible clients to automatically discover the reporting endpoint and send feedback. 3. **Database Integration**: * Added `ConnectionReport` schema to `database/model` and registered it in `database/db.go` for auto-migration. ## Why is this helpful for Restricted Internet Locations? In regions with heavy internet censorship, connection stability is volatile. * **Dynamic Reporting Endpoint**: The `reportUrl` parameter embedded in the subscription link explicitly tells the client *where* to send connection data. * **Bypassing Blocking**: By decoupling the reporting URL from the node address, clients can ensure diagnostic data reaches the panel even if specific node IPs are being interfered with (assuming the panel itself is reachable). * **Real-time Network Intelligence**: This mechanism enables the panel to aggregate "ground truth" data from clients inside the restricted network (e.g., latency, accessibility of specific protocols), allowing admins to react faster to blocking events. * **Protocol Performance Tracking**: Allows comparison of different protocols (Reality vs. VLESS+TLS vs. Trojan) based on real-world latency and success rates from actual users. * **Rapid Troubleshooting**: Administrators can see connection quality trends and rotate IPs/domains proactively when success rates drop, minimizing downtime for users. ## Technical Details * **API Endpoint**: `POST /report` * **Payload Format**: JSON containing `SystemInfo` (Interface), `ConnectionQuality` (Latency, Success), and `ProtocolInfo`. * **Security**: Reports are tied to valid client request contexts (implementation detail: ensure endpoint is rate-limited or authenticated if necessary, though currently designed for open reporting from valid sub links). ## How to Test 1. Update the panel. 2. Generate a subscription link. 3. Observe the `reportUrl` parameter in the link. 4. Simulate a client POST to the report URL and verify the entry in the `ConnectionReports` table.
2026-02-04 10:00:00 +00:00
func (j *CheckClientIpJob) addInboundClientIps(clientEmail string, ips []string) error {
2023-02-28 19:54:29 +00:00
inboundClientIps := &model.InboundClientIps{}
# Pull Request: Connection Reporting System & Improvements for Restricted Networks ## Description This PR introduces a comprehensive **Connection Reporting System** designed to improve the reliability and monitoring of connections, specifically tailored for environments with restricted internet access (e.g., active censorship, GFW). ### Key Changes 1. **New Reporting API (`/report`)**: * Added `ReportController` and `ReportService` to handle incoming connection reports. * Endpoint receives data such as `Latency`, `Success` status, `Protocol`, and Client Interface details. * Data is persisted to the database via the new `ConnectionReport` model. 2. **Subscription Link Updates**: * Modified `subService` to append a `reportUrl` parameter to generated subscription links (VLESS, VMess, etc.). * This allows compatible clients to automatically discover the reporting endpoint and send feedback. 3. **Database Integration**: * Added `ConnectionReport` schema to `database/model` and registered it in `database/db.go` for auto-migration. ## Why is this helpful for Restricted Internet Locations? In regions with heavy internet censorship, connection stability is volatile. * **Dynamic Reporting Endpoint**: The `reportUrl` parameter embedded in the subscription link explicitly tells the client *where* to send connection data. * **Bypassing Blocking**: By decoupling the reporting URL from the node address, clients can ensure diagnostic data reaches the panel even if specific node IPs are being interfered with (assuming the panel itself is reachable). * **Real-time Network Intelligence**: This mechanism enables the panel to aggregate "ground truth" data from clients inside the restricted network (e.g., latency, accessibility of specific protocols), allowing admins to react faster to blocking events. * **Protocol Performance Tracking**: Allows comparison of different protocols (Reality vs. VLESS+TLS vs. Trojan) based on real-world latency and success rates from actual users. * **Rapid Troubleshooting**: Administrators can see connection quality trends and rotate IPs/domains proactively when success rates drop, minimizing downtime for users. ## Technical Details * **API Endpoint**: `POST /report` * **Payload Format**: JSON containing `SystemInfo` (Interface), `ConnectionQuality` (Latency, Success), and `ProtocolInfo`. * **Security**: Reports are tied to valid client request contexts (implementation detail: ensure endpoint is rate-limited or authenticated if necessary, though currently designed for open reporting from valid sub links). ## How to Test 1. Update the panel. 2. Generate a subscription link. 3. Observe the `reportUrl` parameter in the link. 4. Simulate a client POST to the report URL and verify the entry in the `ConnectionReports` table.
2026-02-04 10:00:00 +00:00
jsonIps, err := json.Marshal(ips)
j.checkError(err)
2023-02-28 19:54:29 +00:00
inboundClientIps.ClientEmail = clientEmail
inboundClientIps.Ips = string(jsonIps)
db := database.GetDB()
tx := db.Begin()
defer func() {
if err == nil {
tx.Commit()
} else {
tx.Rollback()
2023-02-28 19:54:29 +00:00
}
}()
err = tx.Save(inboundClientIps).Error
if err != nil {
return err
}
return nil
}
# Pull Request: Connection Reporting System & Improvements for Restricted Networks ## Description This PR introduces a comprehensive **Connection Reporting System** designed to improve the reliability and monitoring of connections, specifically tailored for environments with restricted internet access (e.g., active censorship, GFW). ### Key Changes 1. **New Reporting API (`/report`)**: * Added `ReportController` and `ReportService` to handle incoming connection reports. * Endpoint receives data such as `Latency`, `Success` status, `Protocol`, and Client Interface details. * Data is persisted to the database via the new `ConnectionReport` model. 2. **Subscription Link Updates**: * Modified `subService` to append a `reportUrl` parameter to generated subscription links (VLESS, VMess, etc.). * This allows compatible clients to automatically discover the reporting endpoint and send feedback. 3. **Database Integration**: * Added `ConnectionReport` schema to `database/model` and registered it in `database/db.go` for auto-migration. ## Why is this helpful for Restricted Internet Locations? In regions with heavy internet censorship, connection stability is volatile. * **Dynamic Reporting Endpoint**: The `reportUrl` parameter embedded in the subscription link explicitly tells the client *where* to send connection data. * **Bypassing Blocking**: By decoupling the reporting URL from the node address, clients can ensure diagnostic data reaches the panel even if specific node IPs are being interfered with (assuming the panel itself is reachable). * **Real-time Network Intelligence**: This mechanism enables the panel to aggregate "ground truth" data from clients inside the restricted network (e.g., latency, accessibility of specific protocols), allowing admins to react faster to blocking events. * **Protocol Performance Tracking**: Allows comparison of different protocols (Reality vs. VLESS+TLS vs. Trojan) based on real-world latency and success rates from actual users. * **Rapid Troubleshooting**: Administrators can see connection quality trends and rotate IPs/domains proactively when success rates drop, minimizing downtime for users. ## Technical Details * **API Endpoint**: `POST /report` * **Payload Format**: JSON containing `SystemInfo` (Interface), `ConnectionQuality` (Latency, Success), and `ProtocolInfo`. * **Security**: Reports are tied to valid client request contexts (implementation detail: ensure endpoint is rate-limited or authenticated if necessary, though currently designed for open reporting from valid sub links). ## How to Test 1. Update the panel. 2. Generate a subscription link. 3. Observe the `reportUrl` parameter in the link. 4. Simulate a client POST to the report URL and verify the entry in the `ConnectionReports` table.
2026-02-04 10:00:00 +00:00
func (j *CheckClientIpJob) updateInboundClientIps(inboundClientIps *model.InboundClientIps, clientEmail string, ips []string) bool {
jsonIps, err := json.Marshal(ips)
if err != nil {
logger.Error("failed to marshal IPs to JSON:", err)
return false
}
inboundClientIps.ClientEmail = clientEmail
inboundClientIps.Ips = string(jsonIps)
inbound, err := j.getInboundByEmail(clientEmail)
2024-07-08 21:08:00 +00:00
if err != nil {
logger.Errorf("failed to fetch inbound settings for email %s: %s", clientEmail, err)
return false
}
2023-02-28 19:54:29 +00:00
if inbound.Settings == "" {
2024-07-08 21:08:00 +00:00
logger.Debug("wrong data:", inbound)
return false
2023-02-28 19:54:29 +00:00
}
settings := map[string][]model.Client{}
json.Unmarshal([]byte(inbound.Settings), &settings)
clients := settings["clients"]
shouldCleanLog := false
j.disAllowedIps = []string{}
2023-02-28 19:54:29 +00:00
2024-07-08 21:08:00 +00:00
logIpFile, err := os.OpenFile(xray.GetIPLimitLogPath(), os.O_CREATE|os.O_APPEND|os.O_WRONLY, 0644)
if err != nil {
2024-07-08 21:08:00 +00:00
logger.Errorf("failed to open IP limit log file: %s", err)
return false
}
defer logIpFile.Close()
log.SetOutput(logIpFile)
log.SetFlags(log.LstdFlags)
# Pull Request: Connection Reporting System & Improvements for Restricted Networks ## Description This PR introduces a comprehensive **Connection Reporting System** designed to improve the reliability and monitoring of connections, specifically tailored for environments with restricted internet access (e.g., active censorship, GFW). ### Key Changes 1. **New Reporting API (`/report`)**: * Added `ReportController` and `ReportService` to handle incoming connection reports. * Endpoint receives data such as `Latency`, `Success` status, `Protocol`, and Client Interface details. * Data is persisted to the database via the new `ConnectionReport` model. 2. **Subscription Link Updates**: * Modified `subService` to append a `reportUrl` parameter to generated subscription links (VLESS, VMess, etc.). * This allows compatible clients to automatically discover the reporting endpoint and send feedback. 3. **Database Integration**: * Added `ConnectionReport` schema to `database/model` and registered it in `database/db.go` for auto-migration. ## Why is this helpful for Restricted Internet Locations? In regions with heavy internet censorship, connection stability is volatile. * **Dynamic Reporting Endpoint**: The `reportUrl` parameter embedded in the subscription link explicitly tells the client *where* to send connection data. * **Bypassing Blocking**: By decoupling the reporting URL from the node address, clients can ensure diagnostic data reaches the panel even if specific node IPs are being interfered with (assuming the panel itself is reachable). * **Real-time Network Intelligence**: This mechanism enables the panel to aggregate "ground truth" data from clients inside the restricted network (e.g., latency, accessibility of specific protocols), allowing admins to react faster to blocking events. * **Protocol Performance Tracking**: Allows comparison of different protocols (Reality vs. VLESS+TLS vs. Trojan) based on real-world latency and success rates from actual users. * **Rapid Troubleshooting**: Administrators can see connection quality trends and rotate IPs/domains proactively when success rates drop, minimizing downtime for users. ## Technical Details * **API Endpoint**: `POST /report` * **Payload Format**: JSON containing `SystemInfo` (Interface), `ConnectionQuality` (Latency, Success), and `ProtocolInfo`. * **Security**: Reports are tied to valid client request contexts (implementation detail: ensure endpoint is rate-limited or authenticated if necessary, though currently designed for open reporting from valid sub links). ## How to Test 1. Update the panel. 2. Generate a subscription link. 3. Observe the `reportUrl` parameter in the link. 4. Simulate a client POST to the report URL and verify the entry in the `ConnectionReports` table.
2026-02-04 10:00:00 +00:00
for _, client := range clients {
if client.Email == clientEmail {
limitIp := client.LimitIP
# Pull Request: Connection Reporting System & Improvements for Restricted Networks ## Description This PR introduces a comprehensive **Connection Reporting System** designed to improve the reliability and monitoring of connections, specifically tailored for environments with restricted internet access (e.g., active censorship, GFW). ### Key Changes 1. **New Reporting API (`/report`)**: * Added `ReportController` and `ReportService` to handle incoming connection reports. * Endpoint receives data such as `Latency`, `Success` status, `Protocol`, and Client Interface details. * Data is persisted to the database via the new `ConnectionReport` model. 2. **Subscription Link Updates**: * Modified `subService` to append a `reportUrl` parameter to generated subscription links (VLESS, VMess, etc.). * This allows compatible clients to automatically discover the reporting endpoint and send feedback. 3. **Database Integration**: * Added `ConnectionReport` schema to `database/model` and registered it in `database/db.go` for auto-migration. ## Why is this helpful for Restricted Internet Locations? In regions with heavy internet censorship, connection stability is volatile. * **Dynamic Reporting Endpoint**: The `reportUrl` parameter embedded in the subscription link explicitly tells the client *where* to send connection data. * **Bypassing Blocking**: By decoupling the reporting URL from the node address, clients can ensure diagnostic data reaches the panel even if specific node IPs are being interfered with (assuming the panel itself is reachable). * **Real-time Network Intelligence**: This mechanism enables the panel to aggregate "ground truth" data from clients inside the restricted network (e.g., latency, accessibility of specific protocols), allowing admins to react faster to blocking events. * **Protocol Performance Tracking**: Allows comparison of different protocols (Reality vs. VLESS+TLS vs. Trojan) based on real-world latency and success rates from actual users. * **Rapid Troubleshooting**: Administrators can see connection quality trends and rotate IPs/domains proactively when success rates drop, minimizing downtime for users. ## Technical Details * **API Endpoint**: `POST /report` * **Payload Format**: JSON containing `SystemInfo` (Interface), `ConnectionQuality` (Latency, Success), and `ProtocolInfo`. * **Security**: Reports are tied to valid client request contexts (implementation detail: ensure endpoint is rate-limited or authenticated if necessary, though currently designed for open reporting from valid sub links). ## How to Test 1. Update the panel. 2. Generate a subscription link. 3. Observe the `reportUrl` parameter in the link. 4. Simulate a client POST to the report URL and verify the entry in the `ConnectionReports` table.
2026-02-04 10:00:00 +00:00
if limitIp > 0 && inbound.Enable {
shouldCleanLog = true
# Pull Request: Connection Reporting System & Improvements for Restricted Networks ## Description This PR introduces a comprehensive **Connection Reporting System** designed to improve the reliability and monitoring of connections, specifically tailored for environments with restricted internet access (e.g., active censorship, GFW). ### Key Changes 1. **New Reporting API (`/report`)**: * Added `ReportController` and `ReportService` to handle incoming connection reports. * Endpoint receives data such as `Latency`, `Success` status, `Protocol`, and Client Interface details. * Data is persisted to the database via the new `ConnectionReport` model. 2. **Subscription Link Updates**: * Modified `subService` to append a `reportUrl` parameter to generated subscription links (VLESS, VMess, etc.). * This allows compatible clients to automatically discover the reporting endpoint and send feedback. 3. **Database Integration**: * Added `ConnectionReport` schema to `database/model` and registered it in `database/db.go` for auto-migration. ## Why is this helpful for Restricted Internet Locations? In regions with heavy internet censorship, connection stability is volatile. * **Dynamic Reporting Endpoint**: The `reportUrl` parameter embedded in the subscription link explicitly tells the client *where* to send connection data. * **Bypassing Blocking**: By decoupling the reporting URL from the node address, clients can ensure diagnostic data reaches the panel even if specific node IPs are being interfered with (assuming the panel itself is reachable). * **Real-time Network Intelligence**: This mechanism enables the panel to aggregate "ground truth" data from clients inside the restricted network (e.g., latency, accessibility of specific protocols), allowing admins to react faster to blocking events. * **Protocol Performance Tracking**: Allows comparison of different protocols (Reality vs. VLESS+TLS vs. Trojan) based on real-world latency and success rates from actual users. * **Rapid Troubleshooting**: Administrators can see connection quality trends and rotate IPs/domains proactively when success rates drop, minimizing downtime for users. ## Technical Details * **API Endpoint**: `POST /report` * **Payload Format**: JSON containing `SystemInfo` (Interface), `ConnectionQuality` (Latency, Success), and `ProtocolInfo`. * **Security**: Reports are tied to valid client request contexts (implementation detail: ensure endpoint is rate-limited or authenticated if necessary, though currently designed for open reporting from valid sub links). ## How to Test 1. Update the panel. 2. Generate a subscription link. 3. Observe the `reportUrl` parameter in the link. 4. Simulate a client POST to the report URL and verify the entry in the `ConnectionReports` table.
2026-02-04 10:00:00 +00:00
if limitIp < len(ips) {
j.disAllowedIps = append(j.disAllowedIps, ips[limitIp:]...)
for i := limitIp; i < len(ips); i++ {
log.Printf("[LIMIT_IP] Email = %s || SRC = %s", clientEmail, ips[i])
}
}
}
2023-02-28 19:54:29 +00:00
}
# Pull Request: Connection Reporting System & Improvements for Restricted Networks ## Description This PR introduces a comprehensive **Connection Reporting System** designed to improve the reliability and monitoring of connections, specifically tailored for environments with restricted internet access (e.g., active censorship, GFW). ### Key Changes 1. **New Reporting API (`/report`)**: * Added `ReportController` and `ReportService` to handle incoming connection reports. * Endpoint receives data such as `Latency`, `Success` status, `Protocol`, and Client Interface details. * Data is persisted to the database via the new `ConnectionReport` model. 2. **Subscription Link Updates**: * Modified `subService` to append a `reportUrl` parameter to generated subscription links (VLESS, VMess, etc.). * This allows compatible clients to automatically discover the reporting endpoint and send feedback. 3. **Database Integration**: * Added `ConnectionReport` schema to `database/model` and registered it in `database/db.go` for auto-migration. ## Why is this helpful for Restricted Internet Locations? In regions with heavy internet censorship, connection stability is volatile. * **Dynamic Reporting Endpoint**: The `reportUrl` parameter embedded in the subscription link explicitly tells the client *where* to send connection data. * **Bypassing Blocking**: By decoupling the reporting URL from the node address, clients can ensure diagnostic data reaches the panel even if specific node IPs are being interfered with (assuming the panel itself is reachable). * **Real-time Network Intelligence**: This mechanism enables the panel to aggregate "ground truth" data from clients inside the restricted network (e.g., latency, accessibility of specific protocols), allowing admins to react faster to blocking events. * **Protocol Performance Tracking**: Allows comparison of different protocols (Reality vs. VLESS+TLS vs. Trojan) based on real-world latency and success rates from actual users. * **Rapid Troubleshooting**: Administrators can see connection quality trends and rotate IPs/domains proactively when success rates drop, minimizing downtime for users. ## Technical Details * **API Endpoint**: `POST /report` * **Payload Format**: JSON containing `SystemInfo` (Interface), `ConnectionQuality` (Latency, Success), and `ProtocolInfo`. * **Security**: Reports are tied to valid client request contexts (implementation detail: ensure endpoint is rate-limited or authenticated if necessary, though currently designed for open reporting from valid sub links). ## How to Test 1. Update the panel. 2. Generate a subscription link. 3. Observe the `reportUrl` parameter in the link. 4. Simulate a client POST to the report URL and verify the entry in the `ConnectionReports` table.
2026-02-04 10:00:00 +00:00
}
# Pull Request: Connection Reporting System & Improvements for Restricted Networks ## Description This PR introduces a comprehensive **Connection Reporting System** designed to improve the reliability and monitoring of connections, specifically tailored for environments with restricted internet access (e.g., active censorship, GFW). ### Key Changes 1. **New Reporting API (`/report`)**: * Added `ReportController` and `ReportService` to handle incoming connection reports. * Endpoint receives data such as `Latency`, `Success` status, `Protocol`, and Client Interface details. * Data is persisted to the database via the new `ConnectionReport` model. 2. **Subscription Link Updates**: * Modified `subService` to append a `reportUrl` parameter to generated subscription links (VLESS, VMess, etc.). * This allows compatible clients to automatically discover the reporting endpoint and send feedback. 3. **Database Integration**: * Added `ConnectionReport` schema to `database/model` and registered it in `database/db.go` for auto-migration. ## Why is this helpful for Restricted Internet Locations? In regions with heavy internet censorship, connection stability is volatile. * **Dynamic Reporting Endpoint**: The `reportUrl` parameter embedded in the subscription link explicitly tells the client *where* to send connection data. * **Bypassing Blocking**: By decoupling the reporting URL from the node address, clients can ensure diagnostic data reaches the panel even if specific node IPs are being interfered with (assuming the panel itself is reachable). * **Real-time Network Intelligence**: This mechanism enables the panel to aggregate "ground truth" data from clients inside the restricted network (e.g., latency, accessibility of specific protocols), allowing admins to react faster to blocking events. * **Protocol Performance Tracking**: Allows comparison of different protocols (Reality vs. VLESS+TLS vs. Trojan) based on real-world latency and success rates from actual users. * **Rapid Troubleshooting**: Administrators can see connection quality trends and rotate IPs/domains proactively when success rates drop, minimizing downtime for users. ## Technical Details * **API Endpoint**: `POST /report` * **Payload Format**: JSON containing `SystemInfo` (Interface), `ConnectionQuality` (Latency, Success), and `ProtocolInfo`. * **Security**: Reports are tied to valid client request contexts (implementation detail: ensure endpoint is rate-limited or authenticated if necessary, though currently designed for open reporting from valid sub links). ## How to Test 1. Update the panel. 2. Generate a subscription link. 3. Observe the `reportUrl` parameter in the link. 4. Simulate a client POST to the report URL and verify the entry in the `ConnectionReports` table.
2026-02-04 10:00:00 +00:00
sort.Strings(j.disAllowedIps)
# Pull Request: Connection Reporting System & Improvements for Restricted Networks ## Description This PR introduces a comprehensive **Connection Reporting System** designed to improve the reliability and monitoring of connections, specifically tailored for environments with restricted internet access (e.g., active censorship, GFW). ### Key Changes 1. **New Reporting API (`/report`)**: * Added `ReportController` and `ReportService` to handle incoming connection reports. * Endpoint receives data such as `Latency`, `Success` status, `Protocol`, and Client Interface details. * Data is persisted to the database via the new `ConnectionReport` model. 2. **Subscription Link Updates**: * Modified `subService` to append a `reportUrl` parameter to generated subscription links (VLESS, VMess, etc.). * This allows compatible clients to automatically discover the reporting endpoint and send feedback. 3. **Database Integration**: * Added `ConnectionReport` schema to `database/model` and registered it in `database/db.go` for auto-migration. ## Why is this helpful for Restricted Internet Locations? In regions with heavy internet censorship, connection stability is volatile. * **Dynamic Reporting Endpoint**: The `reportUrl` parameter embedded in the subscription link explicitly tells the client *where* to send connection data. * **Bypassing Blocking**: By decoupling the reporting URL from the node address, clients can ensure diagnostic data reaches the panel even if specific node IPs are being interfered with (assuming the panel itself is reachable). * **Real-time Network Intelligence**: This mechanism enables the panel to aggregate "ground truth" data from clients inside the restricted network (e.g., latency, accessibility of specific protocols), allowing admins to react faster to blocking events. * **Protocol Performance Tracking**: Allows comparison of different protocols (Reality vs. VLESS+TLS vs. Trojan) based on real-world latency and success rates from actual users. * **Rapid Troubleshooting**: Administrators can see connection quality trends and rotate IPs/domains proactively when success rates drop, minimizing downtime for users. ## Technical Details * **API Endpoint**: `POST /report` * **Payload Format**: JSON containing `SystemInfo` (Interface), `ConnectionQuality` (Latency, Success), and `ProtocolInfo`. * **Security**: Reports are tied to valid client request contexts (implementation detail: ensure endpoint is rate-limited or authenticated if necessary, though currently designed for open reporting from valid sub links). ## How to Test 1. Update the panel. 2. Generate a subscription link. 3. Observe the `reportUrl` parameter in the link. 4. Simulate a client POST to the report URL and verify the entry in the `ConnectionReports` table.
2026-02-04 10:00:00 +00:00
if len(j.disAllowedIps) > 0 {
logger.Debug("disAllowedIps:", j.disAllowedIps)
}
2023-02-28 19:54:29 +00:00
db := database.GetDB()
err = db.Save(inboundClientIps).Error
2024-07-08 21:08:00 +00:00
if err != nil {
logger.Error("failed to save inboundClientIps:", err)
return false
}
return shouldCleanLog
2023-02-28 19:54:29 +00:00
}
func (j *CheckClientIpJob) getInboundByEmail(clientEmail string) (*model.Inbound, error) {
2023-02-28 19:54:29 +00:00
db := database.GetDB()
2024-12-16 13:26:47 +00:00
inbound := &model.Inbound{}
2024-12-16 13:26:47 +00:00
err := db.Model(&model.Inbound{}).Where("settings LIKE ?", "%"+clientEmail+"%").First(inbound).Error
2023-02-28 19:54:29 +00:00
if err != nil {
return nil, err
}
2024-12-16 13:26:47 +00:00
return inbound, nil
}