However, before traffic can be decrypted, ProxyMapService must first determine an important detail:

• Is the client using TLS?
• Does the upstream server expect TLS?

In many environments the answers are obvious, but not always. ProxyMapService provides two configuration options that allow you to control this behavior explicitly:

• SslMode
• UpstreamSslMode

Both settings support the same three values:

"No""Yes""Auto"

The default value for both settings is:

"Auto"

Where These Settings Can Be Configured

Like DecryptSSL, both settings can be configured either for a listener or for an individual host rule.

Listener Configuration

"Listen": {    "Port": 5000,    "RejectHttpProxy": false,    "DecryptSSL": true,    "SslMode": "Yes",    "UpstreamSslMode": "No"}

When configured on a listener, the settings apply to every connection received on that listening port (or port range).

This is useful when all traffic arriving on a particular port follows the same protocol.

Host Rule Configuration

The same settings can be configured for individual destinations.

Example:

"HostRules": {    "Items": [        {            "Pattern": "^mysite\\.com$",            "HostPort": 443,            "DecryptSSL": true,            "SslMode": "Yes",            "UpstreamSslMode": "No"        }    ]}

This rule applies only to connections matching both:

• mysite.com
• port 443

Connections to the same host on other ports are unaffected.

Instead of using a regular expression, you can specify a host name directly:

{    "HostName": "mysite.com",    "DecryptSSL": true,    "SslMode": "Yes",    "UpstreamSslMode": "No"}

Since no port is specified, the rule applies to every port for that host.

Host rules override listener settings whenever a connection matches the rule, allowing different SSL behavior for different destinations.

Understanding SslMode

SslMode controls whether the incoming client connection is expected to use SSL/TLS.

The available values are:

No

The incoming connection is treated as plain TCP.

No TLS handshake is expected.

Yes

The incoming connection is always treated as TLS.

ProxyMapService immediately begins TLS negotiation with the client.

Auto

This is the default behavior.

Instead of relying on the listening port, ProxyMapService examines the first two bytes received from the client.

A TLS ClientHello always begins with:

0x16 0x03

If this signature is detected, the connection is treated as TLS.

Otherwise, it is processed as an unencrypted connection.

This automatic detection allows HTTP and HTTPS traffic to coexist on the same listener without requiring separate ports.

Understanding UpstreamSslMode

UpstreamSslMode controls how ProxyMapService connects to the destination server.

Unlike SslMode, which examines the client connection, this setting determines whether the outbound connection should be encrypted.

The available values are the same:

No

ProxyMapService always connects to the upstream server using plain TCP.

Yes

ProxyMapService always establishes a TLS connection to the upstream server.

Auto

This is the default behavior.

Instead of inspecting traffic, ProxyMapService determines whether TLS should be used based on the destination port.

The following ports are treated as secure by default:

• 443 (HTTPS)
• 465 (SMTPS)
• 563 (NNTPS)
• 636 (LDAPS)
• 990 (FTPS)
• 992 (Telnet over TLS)
• 993 (IMAPS)
• 995 (POP3S)
• 3269 (Microsoft Global Catalog over SSL)
• 8443 (Alternative HTTPS)

Connections to these ports are established using TLS.

Connections to other ports use plain TCP unless UpstreamSslMode is explicitly set to Yes.

When Should You Override Auto?

For most deployments, Auto is the recommended setting for both options.

However, explicit configuration is useful when working with non-standard environments.

Typical examples include:

• HTTPS services running on custom ports.
• Plain HTTP services listening on port 443.
• Legacy applications that tunnel TLS over unexpected ports.
• Environments where protocol detection must be disabled for compatibility or performance reasons.

In these situations, setting SslMode or UpstreamSslMode to Yes or No removes any ambiguity and ensures ProxyMapService uses the desired protocol.

Conclusion

SslMode and UpstreamSslMode give you precise control over how ProxyMapService handles encrypted connections.

SslMode determines whether the client connection is encrypted, while UpstreamSslMode determines whether the connection to the destination server should use TLS.

In most cases, the default Auto mode works without any additional configuration by automatically detecting TLS on incoming connections and using well-known secure ports for outbound connections.

When working with non-standard network topologies or custom protocols, these settings allow ProxyMapService to communicate correctly with both clients and upstream servers without requiring changes to the application itself.

1. Open the story/chapter you want to copy from and wait until the page is fully loaded.

2. Open the browser’s Developer Tools:

   • Chrome / Edge: press F12 or Ctrl + Shift + I
   • Firefox: press F12 or Ctrl + Shift + I
   • Safari: enable the Develop menu first, then choose Develop → Show JavaScript Console

3. Go to the Console tab.

4. Paste and run this command:

document.onselectstart = null;

5. After that, you should be able to select text on the page normally.
6. Highlight the text you want.
7. In the Console, run:

console.log(window.getSelection().toString())

8. The selected text will be printed in the console. You can then select it there and copy it to your clipboard with Ctrl+C.

A couple of notes:

• Make sure the chapter has finished loading before you start.
• If the selection doesn’t work immediately, refresh the page and try again.
• This method was tested in a desktop browser using Developer Tools.

Hope this helps someone.

Web Proxy Checker is a multi-threaded application. In the Check Threads setting, you can define how many worker threads will be used during proxy verification. A thread is an independent execution unit that can process tasks in parallel with other threads.

When Async Tasks Per Thread is enabled, each thread can handle multiple proxy checks simultaneously. Instead of waiting for one proxy request to finish before starting the next one, the thread launches several asynchronous tasks and processes many connections at the same time.

For example:

• Check Threads: 20
• Async Tasks Per Thread: 50

This means that up to 20 × 50 = 1,000 asynchronous proxy checks can run concurrently.

The result is a significant speed increase, especially when checking large proxy lists. In real-world usage, verifying a list of 2,000 proxies takes roughly 30 seconds, depending on proxy quality, target settings, and network conditions.

If you’re working with large proxy databases, enabling asynchronous tasks is one of the most effective ways to maximize checking performance.

To help reduce those costs, ProxyMapService includes an HTTP response caching feature. When enabled, frequently requested resources can be served directly from the local cache instead of being downloaded through the upstream proxy again. In many scenarios this significantly reduces bandwidth consumption and lowers operating costs.

Enabling the Cache

Caching is disabled by default. To enable it, set Enabled to true in the Cache section of appsettings.json:

"Cache": {    "Enabled": true,    "DbPath": "c:\\temp\\cache\\proxymap.db",    "CacheDir": "c:\\temp\\cache\\files"}

Configuration options:

What Gets Cached

ProxyMapService only caches responses that meet all of the following conditions:

• The request method is GET
• The response status code is 200 OK
• The response contains a valid content length
• The response matches a configured cache rule
• The response is considered cacheable according to the cache policy evaluation process

This approach avoids storing dynamic or non-cacheable content while keeping the cache efficient.

Cache Storage Structure

Cached responses are split into two parts:

Metadata

Metadata is stored in a SQLite table named cache_entries.

CREATE TABLE cache_entries(    key TEXT PRIMARY KEY,    host TEXT,    url TEXT,    etag TEXT,    cache_control TEXT,    date TEXT,    expires TEXT,    last_modified TEXT,    header_length INTEGER,    content_length INTEGER,    content_type TEXT,    created_at TEXT,    last_access TEXT)

The table stores information required to evaluate cache validity, including HTTP cache headers such as ETag, Cache-Control, Expires, and Last-Modified.

Response Body

The actual response content is stored as a binary file under CacheDir.

Each cache entry receives a SHA-256 key generated from:

host + url

Example key:

18c97f79e87cdfdd7fd0cce3048cc6643b18ed7b154efe859d9fab09209d012a

Example cache file location:

c:\temp\cache\files\18\18c9\18c97f79e87cdfdd7fd0cce3048cc6643b18ed7b154efe859d9fab09209d012a.bin

The nested directory structure prevents large numbers of files from accumulating in a single folder.

Defining Cache Rules

Caching is controlled through CacheRules configured within a host rule.

Example:

{    "Pattern": "gstatic\\.com$",    "HostPort": 443,    "Action": "Bypass",    "DecryptSSL": true,    "CacheRules": {        "Items": [            {                "Pattern": "/images",                "ContentTypePattern": "image/",                "MaxAge": 60            }        ]    }}

This configuration instructs ProxyMapService to cache:

• Requests sent to hosts matching gstatic\.com$
• URLs matching /images
• Responses whose Content-Type matches image/
• Responses younger than 60 seconds

HTTPS Traffic Requires SSL/TLS Decryption

Notice the following setting:

"DecryptSSL": true

This is required when caching HTTPS traffic.

Without SSL/TLS decryption, ProxyMapService cannot inspect the request path, response headers, or content type, making cache decisions impossible.

If you are not familiar with SSL/TLS interception in ProxyMapService, see the previous article, SSL/TLS Traffic Decryption in ProxyMapService, which explains the setup process in detail.

Available Cache Rule Options

Cache rules support several filters and cache-control options.

Pattern

Matches the request URL using a regular expression.

{    "Pattern": "/images"}

Only requests whose URL matches the expression are considered.

AcceptPattern

Matches the request’s Accept header.

{    "AcceptPattern": "image/"}

This can be useful when the same URL may return different content types depending on client preferences.

ContentTypePattern

Matches the response Content-Type header.

{    "ContentTypePattern": "image/"}

The response must match this pattern before it can be stored or served from cache.

MaxAge

Defines a fixed lifetime in seconds.

{    "MaxAge": 3600}

In this example, cached content expires one hour after it is stored.

When MaxAge is specified, ProxyMapService calculates:

CreatedAt + MaxAge

If the current time exceeds that value, the cache entry is treated as expired regardless of any HTTP cache headers.

IgnoreCacheControl

{    "IgnoreCacheControl": true}

When enabled, ProxyMapService ignores the server’s Cache-Control, Expires, and validation directives.

Only the rule’s MaxAge setting determines whether the cached response can be used.

This can be useful when caching content from servers that provide overly restrictive cache headers.

How Cache Validation Works

When a cached entry is requested, ProxyMapService evaluates whether the entry can still be used.

The evaluation process follows standard HTTP caching semantics.

1. Cache-Control: no-store

Cache-Control: no-store

The response must never be reused.

Result:

Refresh

The content is downloaded again from the origin server.

2. Cache-Control: no-cache

Cache-Control: no-cache

The response may be stored, but it must be revalidated before use.

If the response contains validators such as ETag or Last-Modified:

Revalidate

Otherwise:

Refresh

3. Freshness Lifetime Calculation

ProxyMapService determines freshness using the following priority order.

max-age

Cache-Control: max-age=3600

This has the highest priority.

Expires

If no max-age exists:

Expires: Wed, 25 Jun 2025 12:00:00 GMT

The lifetime is calculated as:

Expires - Date

Heuristic Expiration

If neither max-age nor Expires exists, ProxyMapService falls back to a heuristic.

It calculates approximately 10% of:

Date - Last-Modified

For example, if a resource was last modified 10 days before the response date, the cache lifetime becomes roughly 1 day.

If that information is unavailable, a default lifetime of 10 minutes is used.

Stale-While-Revalidate Support

ProxyMapService also honors the stale-while-revalidate directive.

Example:

Cache-Control: max-age=60, stale-while-revalidate=300

Behavior:

• First 60 seconds → content is considered fresh
• Next 300 seconds → stale content may still be served
• Background revalidation can occur during this period

This reduces latency and unnecessary traffic while keeping content reasonably fresh.

Validation Using ETag and Last-Modified

When cached content becomes stale, ProxyMapService checks whether validation information is available.

Supported validators:

ETag: "abc123"

and

Last-Modified: Wed, 25 Jun 2025 12:00:00 GMT

If either validator exists, the entry can be revalidated instead of fully downloaded again.

This often results in a lightweight HTTP validation request rather than retransferring the entire resource.

Typical Use Cases

Traffic caching is especially effective for:

• Images
• JavaScript bundles
• CSS files
• Fonts
• Static CDN content
• Frequently requested API responses with predictable cache headers

A common pattern is to cache content from CDN providers such as Google Static Content, Cloudflare, or other asset delivery networks.

Final Thoughts

For environments where proxy traffic directly affects operating costs, caching can provide immediate savings. By storing frequently requested resources locally and honoring standard HTTP caching semantics, ProxyMapService reduces bandwidth consumption while still respecting content freshness rules.

In practice, even a small set of well-targeted cache rules for static assets can significantly reduce upstream traffic and improve response times for clients.

This becomes important when you want ProxyMapService to do more than simple forwarding. For example, caching static content such as images, JavaScript files, stylesheets, fonts, or other assets requires access to the decrypted HTTP payload. Without SSL/TLS decryption, the proxy can only see an encrypted byte stream and cannot analyze or cache the content.

ProxyMapService supports SSL/TLS traffic decryption by operating as a man-in-the-middle (MITM) proxy. This allows HTTPS traffic to be inspected, modified, cached, or routed using the same rule engine that is available for regular HTTP traffic.

ProxyMapService already includes support for content caching, but that topic deserves its own article. In this post, we’ll focus only on SSL/TLS decryption and the certificate configuration required to make it work.

Creating a Root CA Certificate

Before ProxyMapService can decrypt HTTPS traffic, it must be able to generate certificates for target hosts dynamically. To do that, a trusted root Certificate Authority (CA) certificate is required.

The easiest way to create one is to use the CreateRootCA console utility included with ProxyMapService.

By default, the utility creates the certificate files in the .proxymap directory located in the current user’s home folder.

The generated files include:

• A PKCS#12 (.p12) file containing the certificate and private key
• A public certificate (.cer)
• A PEM-encoded public certificate (.pem)

Installing the Certificate

The generated certificate must be installed into the appropriate Windows certificate store.

Stand-alone Mode

If ProxyMapService is running as a stand-alone application (ProxyMapService.exe), install the root certificate into the Trusted Root Certification Authorities store of the Current User.

Open the certificate manager:

certmgr.msc

Then import the generated root certificate into:

Current User └─ Trusted Root Certification Authorities

IIS Hosting

If ProxyMapService is hosted by IIS, install the certificate into the Personal certificate store of the Local Computer.

Open:

certlm.msc

Then import the certificate into:

Local Computer └─ Personal

The application pool identity must have access to the certificate’s private key.

Configuring the Root Certificate

After the certificate has been installed, ProxyMapService must be configured to locate it.

Example configuration:

"SslServerOptions": {    "EnabledSslProtocols": "Tls11,Tls12,Tls13",    "ClientCertificateRequired": false,    "CheckCertificateRevocation": false,    "CACertificate": {        "StoreLocation": "LocalMachine",        "StoreName": "My",        "Subject": "CN=DO_NOT_TRUST_ProxyMapRoot"    }}

In this example, ProxyMapService searches for a certificate with the following subject:

CN=DO_NOT_TRUST_ProxyMapRoot

inside the My (Personal) certificate store of the Local Machine certificate location.

Understanding SslServerOptions

SslServerOptions controls how ProxyMapService behaves when acting as the TLS server toward connecting clients.

EnabledSslProtocols

Specifies which TLS protocol versions are allowed.

"EnabledSslProtocols": "Tls11,Tls12,Tls13"

Only the listed protocol versions will be accepted during TLS negotiation.

In most environments, TLS 1.2 and TLS 1.3 are sufficient. TLS 1.1 is typically enabled only for compatibility with legacy clients.

ClientCertificateRequired

Controls whether the client must present a certificate during the TLS handshake.

"ClientCertificateRequired": false

When set to false, clients authenticate using standard HTTPS behavior.

When set to true, mutual TLS (mTLS) is required and clients must provide a valid certificate.

CheckCertificateRevocation

Controls certificate revocation checking.

"CheckCertificateRevocation": false

When enabled, Windows performs online revocation checks using CRL or OCSP endpoints during certificate validation.

Disabling revocation checks can reduce connection latency and avoid failures in isolated environments where revocation services are unavailable.

CACertificate

Specifies the root CA certificate used by ProxyMapService to generate certificates for intercepted HTTPS hosts.

The certificate is identified using:

• StoreLocation
• StoreName
• Subject

The private key associated with this certificate is required for successful SSL/TLS interception.

Understanding SslClientOptions

SslClientOptions controls how ProxyMapService authenticates when connecting to upstream HTTPS servers.

Example configuration:

"SslClientOptions": {    "EnabledSslProtocols": "Tls11,Tls12,Tls13",    "CheckCertificateRevocation": false}

EnabledSslProtocols

Specifies which TLS protocol versions ProxyMapService may use when establishing outbound HTTPS connections.

"EnabledSslProtocols": "Tls11,Tls12,Tls13"

Only the configured protocols will be offered during negotiation with the remote server.

CheckCertificateRevocation

Controls revocation checking for certificates presented by upstream servers.

"CheckCertificateRevocation": false

When enabled, certificate revocation status is verified before the server certificate is accepted.

This helps detect certificates that have been revoked by the issuing authority.

Enabling SSL/TLS Decryption

Once the certificate has been installed and the SSL options are configured, SSL/TLS decryption can be enabled using the DecryptSSL setting.

Decryption can be enabled globally for a listening port or selectively for specific host rules.

Enabling Decryption on a Listening Port

Example:

"Listen": {    "Port": 10001,    "RejectHttpProxy": false,    "DecryptSSL": true}

With this configuration, all HTTPS traffic received on port 10001 will be decrypted and processed by ProxyMapService.

This is usually the simplest configuration when all traffic arriving on the listener should be inspected.

Enabling Decryption for Specific Hosts

Sometimes only a subset of HTTPS traffic needs to be decrypted.

In that case, decryption can be enabled within host rules.

Example:

"HostRules": {    "Items": [        {            "Pattern": "google\\.com$",            "HostPort": 443,            "DecryptSSL": true        }    ]}

In this configuration, only HTTPS traffic matching google.com on port 443 will be decrypted.

All other HTTPS traffic will continue to pass through without interception.

This approach is useful when SSL inspection is required only for selected destinations.

Verifying the Configuration

After enabling SSL/TLS decryption:

1. Start ProxyMapService.
2. Configure a browser or application to use the proxy.
3. Open an HTTPS website.
4. Verify that no certificate warnings are displayed.
5. Check ProxyMapService logs to confirm that decrypted HTTP requests and responses are being processed.

If certificate warnings appear, verify that:

• The root CA certificate is installed in the correct certificate store.
• The configured certificate subject matches the installed certificate.
• The certificate includes a private key.
• The service account has permission to access the private key.

Conclusion

SSL/TLS decryption is a prerequisite for advanced HTTPS traffic processing in ProxyMapService. Once a trusted root CA certificate is installed and configured, the service can inspect encrypted traffic just as it does regular HTTP traffic.

This capability enables scenarios such as request inspection, response modification, traffic analysis, selective routing, and content caching. In a future post, we’ll take a closer look at the caching subsystem and how it can be used to efficiently serve static content directly from ProxyMapService.

Each local port automatically receives its own session ID and keeps it for the configured StickyProxyLifetime. This allows applications that only support simple IP:PORT proxies to work with modern session-based proxy providers.

Until now, session management in ProxyMapService was completely automatic. While this works well for many use cases, some applications need direct control over when sessions are created, rotated, or discarded.

The latest version of ProxyMapService introduces a Session API that allows applications and scripts to inspect, reset, and create sessions on demand.

How sessions work

Assume the following configuration:

{  "Listen": {    "PortRange": {      "Start": 10201,      "End": 10300    },    "StickyProxyLifetime": 10  }}

When traffic is sent through port 10201, ProxyMapService generates a session ID:

10201 → session LZpmRqdu

All requests made through this port will use the same sticky session until it expires.

The new Session API exposes this information and allows manual control over the session lifecycle.

Enabling Session API

For security and compatibility reasons, Session API is disabled by default.

To enable it, add the following section to your appsettings.json:

{  "SessionAPI": {    "Enabled": true,    "Domain": "portmapper"  }}

Configuration Options

With the configuration above, Session API can be accessed using requests such as:

curl -x http://127.0.0.1:10201 http://portmapper/session/

Using an Empty Domain

The Domain setting is optional and may be set to an empty string:

{  "SessionAPI": {    "Enabled": true,    "Domain": ""  }}

When Domain is empty, Session API endpoints become available directly on the mapped proxy port.

For example:

curl http://127.0.0.1:10201/session/

This can be convenient when working with local tools or scripts that do not support custom hostnames.

Get Current Session

Returns information about the session currently assigned to a port.

Example:

curl -x http://127.0.0.1:10201 http://portmapper/session/

Response:

{  "session_id": "LZpmRqdu",  "expires_at": "Wed, 10 Jun 2026 16:09:43 GMT",  "expired": false}

If the session is still active, repeated calls return the same information.

When the sticky session expires, ProxyMapService automatically generates a new session ID and the endpoint will return the new session details.

This can be useful for monitoring session state or checking how much time remains before rotation.

Reset Current Session

Sometimes you want to force a session change without waiting for the expiration timer.

The /session/reset endpoint removes the current session associated with the port.

Example:

curl -x http://127.0.0.1:10201 http://portmapper/session/reset

Response:

{  "success": true}

After the reset, the next request through port 10201 will automatically create a new session.

Typical use cases:

• detected or blocked IP address
• captcha escalation
• failed scraping workflow
• manual IP rotation

Create a New Session Immediately

The /session/new endpoint creates a new session immediately and assigns it to the port.

Example:

curl -x http://127.0.0.1:10201 http://portmapper/session/new

Response:

{  "session_id": "uawxmttg",  "expires_at": "Wed, 10 Jun 2026 16:19:48 GMT",  "expired": false}

Unlike /session/reset, which simply removes the current session, /session/new generates and activates a replacement session instantly.

This is useful when an application wants to rotate identities proactively while continuing to use the same local proxy port.

Why Not Just Change Ports?

A common question is why you would need a Session API if every port already has its own sticky session.

In practice, many scraping and automation systems assign a specific role to each local proxy port. For example:

127.0.0.1:10201 → Worker A127.0.0.1:10202 → Worker B127.0.0.1:10203 → Worker C

Workers may maintain their own queues, browser profiles, cookies, account assignments, or internal state tied to a particular proxy endpoint.

Changing ports is not always practical because it may require updating application configuration, restarting workers, or reassigning tasks.

With Session API, the application can keep using the same local proxy port while rotating the underlying sticky session whenever necessary.

Practical Examples

Session API can be useful when:

• a target website starts returning captchas
• an IP address becomes blocked or rate-limited
• a scraping task needs a fresh identity immediately
• monitoring systems need visibility into session expiration
• applications want explicit control over session rotation timing

All of this can be done without restarting ProxyMapService and without changing the local proxy endpoint used by the application.

Summary

ProxyMapService was originally designed to make sticky proxies available to software that only understands simple IP:PORT proxy lists.

The new Session API adds direct control over the sticky sessions behind each mapped port.

Available endpoints:

• GET /session/ — get information about the current session
• GET /session/reset — remove the current session
• GET /session/new — create and activate a new session immediately

This makes it easier to build scraping, automation, and data collection systems that need predictable control over proxy identities while continuing to use ordinary local proxy ports.

192.168.1.100:1080

The problem was that pip doesn’t support SOCKS proxies out of the box. Normally, you’d install PySocks to enable that — but since pip itself wasn’t working, that wasn’t an option.

I used the ProxyMapService to expose the SOCKS5 proxy as a local HTTP proxy. Here’s the rule I configured:

{  "Listen": {    "Port": 10000,    "RejectHttpProxy": false  },  "Authentication": {    "Required": false,    "Verify": false,    "SetAuthentication": false  },  "ProxyServers": {    "Items": [      {        "Host": "192.168.1.100",        "Port": 1080,        "ProxyType": "Socks5"      }    ]  }}

After that, pip started working by pointing it to the local HTTP proxy:

pip install cython --proxy http://127.0.0.1:10000Collecting cython  Using cached cython-3.2.4-cp311-cp311-win_amd64.whl.metadata (7.7 kB)Using cached cython-3.2.4-cp311-cp311-win_amd64.whl (2.8 MB)Installing collected packages: cythonSuccessfully installed cython-3.2.4

🎉

Many modern proxy providers sell so-called sticky proxies (also known as session-based proxies). This is a very popular solution for scraping, automation, data collection, and working around anti-bot protections.

What is a sticky proxy?

A sticky proxy is a proxy server that “locks” one IP address to you for a certain amount of time (for example, 5 or 10 minutes) using a session. Usually, the session is defined via the username, for example:

user-session-ABC123-sessTime-10:password@proxy_host:proxy_port

While the session is active, you will access the internet from the same IP address. When the time expires or you change the session ID, you get a new IP.

Today, most large proxy providers (residential, mobile, ISP) work exactly this way: you connect to a single host and port, and IP rotation is controlled via parameters in the username.

The problem: not all software supports sticky proxies

Many applications (scraping software, old parsers, bots, automation tools):

• ❌ cannot work with proxies that require authentication
• ❌ cannot manage sessions
• ❌ expect just a list of IP:PORT, without username and password

Because of this, they cannot be directly connected to modern sticky proxy providers.

The solution: map local TCP ports through sticky proxies

The idea is very simple:

• We run a local service
• It opens a range of local ports
• Each local port:
  • automatically connects to the sticky proxy
  • uses its own separate session
• As a result:
  • 127.0.0.1:5001 → sticky proxy session AAA1
  • 127.0.0.1:5002 → sticky proxy session AAA2
  • 127.0.0.1:5003 → sticky proxy session AAA3
  • and so on

And your software just works with regular proxies without authentication:

127.0.0.1:5001127.0.0.1:5002127.0.0.1:5003

Ready-made solution: ProxyMapService

For this purpose, the following open-source project works perfectly:

👉 ProxyMapService
https://github.com/optinsoft/ProxyMapService

It can:

• map port ranges
• automatically manage sticky sessions
• work with HTTP / SOCKS proxies
• modify / generate username parameters

Configuration example

Here is an example config:

"ProxyMappings": [  {    "Listen": {      "PortRange": {        "Start": 10001,        "End": 10100      },      "RejectHttpProxy": false,      "StickyProxyLifetime": 10    },    "Authentication": {      "Required": false,      "Verify": false,      "SetAuthentication": false,      "RemoveAuthentication": false    },    "ProxyServers": {      "Items": [        {          "Host": "PROXY_IP",          "Port": PROXY_PORT,          "ProxyType": "Http",          "Username": "USERNAME",          "Password": "PASSWORD",          "UsernameParameters": [            {              "Name": "zone",              "Value": "custom"            },            {              "Name": "region",              "Value": "US"            },            {              "Name": "session",              "Value": "^[A-Za-z]{8}",              "SessionId": true            },            {              "Name": "sessTime",              "Value": "$sessTime",              "Default": "10",              "SessionTime": true            }          ]        }      ]    }  }]

⚠️ In this example you need to replace:

• PROXY_IP
• PROXY_PORT
• USERNAME
• PASSWORD

with the values provided by your proxy provider.

How does it work in practice?

• ProxyMapService opens local ports 10001–10100

• Each port:

  • automatically generates a new sticky session
  • keeps it for StickyProxyLifetime = 10 minutes

• You just set in your software:

127.0.0.1:10001127.0.0.1:10002127.0.0.1:10003...

Conclusion

If your software:

• doesn’t support proxy authentication
• doesn’t support sessions
• only works with IP:PORT lists

➡️ ProxyMapService solves this problem completely, allowing you to use modern sticky proxies without modifying your software.

Useful for:

• scraping software
• bots
• automation tools
• legacy tools
• and basically any software with poor proxy support

The Challenge: Managing Complex Usernames

Sometimes, proxy usernames need to encode more information than just the account identifier.

For example, a proxy might look like this:

http://user-zone-custom-region-US-session-1234567-sessionTime-5:1111@127.0.0.1:8888

Username part of the proxy is user-zone-custom-region-US-session-1234567-sessionTime-5.

While this format might be necessary for other parts of the system or for identification, it complicates the standard authentication process by requiring the system to ignore the extra parts (zone, region, session, etc.) and focus solely on the actual username.

The Solution: Introducing ParseUsernameParameters

To address this need for cleaner authentication, we’ve introduced a new configuration parameter called ParseUsernameParameters. This boolean parameter resides within the Authentication section of the appsettings.json file.

• Parameter Name: ParseUsernameParameters
• Allowed Values: true or false (default is false)

What Does This Parameter Do?

When set to true, the ProxyMapService will parse the username string during authentication. It splits the username using the hyphen (-) delimiter. Crucially, only the first segment (the part before the first hyphen) is used for the authentication check. The remaining segments are ignored.

How It Works (Example)

Let’s take a look at the authentication logic with ParseUsernameParameters=true:

1. Input Username (part of the proxy):

   "user-zone-custom-region-US-session-1234567-sessionTime-5"

2. Authentication Logic (with ParseUsernameParameters=true):

   • The username string user-zone-custom-region-US-session-1234567-sessionTime-5 is split using the - character.
   • The resulting parts are: ["user", "zone", "custom", "region", "US", "session", "1234567", "sessionTime", "5"]
   • Authentication Check: The system compares the first part, user, to the configured Username value (e.g., "user" from the example config). The rest of the parts are completely ignored for authentication.

Configuration Example (appsettings.json)

Here’s how you would enable this feature in your appsettings.json:

{  "Authentication": {    // ... other authentication settings ...    "Required": true,    "Verify": true,    "ParseUsernameParameters": true,    "Username": "user",  // This is the base username to compare against    "Password": "1111"    // Password  }}

We’re pleased to announce the release of Web Proxy Checker version 2.111 – our reliable tool for testing proxy server functionality now includes improved handling for CONNECT (HTTPS) proxies with non-standard authentication behavior.

Standard Proxy Authentication Flow

When connecting to a proxy requiring Basic Authentication, the expected protocol is:

1. Client (browser or our tool) connects without credentials
2. Proxy responds with “407 Proxy Authentication Required”
3. Client reconnects with the Proxy-Authorization HTTP header
4. Connection proceeds if credentials are valid

This standard flow is used by all major browsers (Chrome, Firefox, Edge) and has been Web Proxy Checker’s default behavior.

The Challenge: Non-Compliant Proxies

During testing, we identified proxies that don’t follow authentication standards. Instead of returning the proper 407 error, they immediately close connections when credentials are missing. This creates a compatibility issue where legitimate authentication attempts fail.

New Feature: “Connect Basic Authentication” Setting

Version 2.111 introduces a solution on the HTTP tab: the new “Connect Basic Authentication” option.

How it works:

• Disabled (Default): Standard behavior – waits for 407 response before sending credentials
• Enabled: Immediately includes Proxy-Authorization header in the first connection attempt
• Result: Compatibility with proxies that require immediate authentication

Usage Recommendations:

• Most users should keep this setting disabled (works with standard proxies)
• Enable only when encountering proxies that close connections without 407 responses
• Particularly useful for certain corporate or custom proxy setups

Quick Setup:

1. Launch Web Proxy Checker v2.111
2. Go to the HTTP tab
3. Find “Connect Basic Authentication” checkbox
4. Enable for problematic proxies, disable for standard ones

What This Means for You:

• ✓ Wider proxy compatibility
• ✓ No more failed connections with non-standard proxies
• ✓ Backward compatibility maintained
• ✓ Easy toggle between authentication modes

Upgrade Today

Download Web Proxy Checker v2.111 and experience improved compatibility with all your proxy servers!

1. Enabling Event Log Logging

To enable writing events to the Windows Event Log, you need to make a small change in your project’s configuration file — appsettings.json.

Add the EventLog section within the Logging block, specifying the desired minimum logging level. The example below sets the level to “Information”:

{  "Logging": {    "EventLog": {      "LogLevel": {        "Default": "Information"      }    }  }}

💡 Note: The Default level within the EventLog section determines the minimum level (Trace, Debug, Information, Warning, Error, Critical) at which messages will be written to the log.

2. Mandatory Step: Registering the Event Source (PowerShell)

Attention! For messages to be successfully displayed in the Event Log and for the system to correctly identify their source and formatting, it is necessary to register the event source with the name ProxyMapService beforehand.

Event source registration is only required once upon installation or update of the service.

Use PowerShell run as administrator and execute the following command. This command creates the necessary registry key:

New-EventLog -LogName Application -Source ProxyMapService

• New-EventLog: The cmdlet used to create a new event source.
• -LogName Application: Specifies that the source will write to the standard “Application” log.
• -Source ProxyMapService: Sets the source name, which must match the name used within the service code.

3. Viewing the Events

After configuring appsettings.json and registering the source, restart the ProxyMapService. All events at the Information level and above will now be available for viewing in the Windows Event Viewer under Windows Logs $\rightarrow$ Application.

Look for messages with the Source: ProxyMapService.

🔗 Source Code and Discussion: As always, you can find the latest version of the project on GitHub: https://github.com/optinsoft/ProxyMapService

tz_names = pytz.country_timezones.get(country.upper(), [])

When I needed similar functionality in Delphi, I was surprised to find that there wasn’t a readily available library to get IANA timezone names for countries.

After searching without success, I decided to create my own solution:

https://github.com/optinsoft/CountryTimezone

Here’s a practical example that demonstrates how to get a random timezone name and its UTC offset for a given country:

uses CountryTimezone, TZDB;type   TTimezoneAndOffset = record        name: String;        offset: Integer;   end;function GetRandomTimezoneAndOffset(country: String): TTimezoneAndOffset;var  LCTZDict: TCountryTimezoneDictionary;  LCTZList: TStringList;  tz: TBundledTimeZone;begin  LCTZDict := TCountryTimezoneDictionary.Create();  LCTZList := TStringList.Create;  try    LCTZDict.GetCountryTimezones(country, LCTZList);    Result.name := LCTZList[Random(LCTZList.Count)];    tz := TBundledTimeZone.GetTimeZone(Result.name);    Result.offset := Trunc(tz.UtcOffset.TotalMinutes);  finally    LCTZList.Free;    LCTZDict.Free;  end;end;

This function:

1. Creates a country timezone dictionary
2. Retrieves all timezone names for the specified country
3. Selects a random timezone from the list
4. Uses TZDB to get the UTC offset in minutes for that timezone

When working with JavaScript, there are times you might want to automatically rename variables or functions across your code — perhaps for obfuscation, code transformation, or refactoring. Doing this safely, without accidentally breaking your program, requires understanding how your code is structured — and that’s where the Abstract Syntax Tree (AST) comes in.

In this post, we’ll look at how to rename variable and function declarations using ASTs, with a simple utility renamedecl.

🌳 What Is an AST?

An Abstract Syntax Tree (AST) is a structured, tree-like representation of your source code.
Instead of dealing with raw text, you work with objects that represent program constructs like variables, functions, loops, and expressions.

For example, the code:

const x = 5;console.log(x);

can be represented (simplified) as:

{  type: "Program",  body: [    {      type: "VariableDeclaration",      declarations: [        {          type: "VariableDeclarator",          id: { type: "Identifier", name: "x" },          init: { type: "Literal", value: 5 }        }      ]    },    {      type: "ExpressionStatement",      expression: {        type: "CallExpression",        callee: {          object: { name: "console" },          property: { name: "log" }        },        arguments: [{ type: "Identifier", name: "x" }]      }    }  ]}

By working with this structure, you can programmatically modify parts of your code (e.g. change x to width) and then regenerate valid JavaScript source code.

🧩 Tools: Acorn, Escodegen

• Acorn — a fast, lightweight JavaScript parser. It converts JS source code into an AST.
• Escodegen — generates readable JavaScript code from an AST.

Scopes

Scopes — just like in real code, variables and functions in an AST exist within scopes (e.g., global, function, block). When renaming identifiers, you need to make sure you don’t accidentally rename a variable from an outer scope that has the same name.

🚀 Introducing renamedecl

renamedecl is the lightweight tool for renaming variables and functions in JS code based on an AST.

The function renameDeclarations(ast, rename, initscope?) walks through your AST, finds all declarations (variables, function names, parameters, etc.), and lets you rename them safely according to the rules you define.

It can be used in two main ways:

1. Automatic Renaming

You can rename every variable and function in a consistent way — for example, to obfuscate or anonymize code.

const acorn = require('acorn');const escodegen = require('escodegen');const { renameDeclarations } = require('renamedecl');const originalCode = `function add(x, y) {    const result = x + y;    return result;}`;const ast = acorn.parse(originalCode, {    ecmaVersion: 2020,    sourceType: 'script'});// Rename all identifiers sequentiallyrenameDeclarations(    ast,    (id, scope) => `v${++scope.varNum}`,    scope => { scope.varNum = 0; });const newCode = escodegen.generate(ast);console.log(newCode);

Output:

function v1(v2, v3) {    const v1 = v2 + v3;    return v1;}

Here, every declared identifier got renamed with a consistent numbering scheme, respecting the correct scope hierarchy.

2. Custom Rename Mapping

You can also define your own rename map to transform specific variable or function names.

const renameMap = {    x: 'width',    y: 'height',    result: 'sum'};renameDeclarations(ast, id => renameMap[id.name]);

This is great for refactoring, such as renaming variables to more meaningful names.

🧠 How Scoping Works

renamedecl automatically tracks scopes as it traverses the AST.
When it enters a new function or block, it creates a new scope object.
This ensures that two variables named x in different functions don’t get mixed up:

function outer() {    const x = 10;    function inner() {        const x = 20;        console.log(x);    }    inner();}

Both x variables live in different scopes. The renaming logic keeps that distinction intact — so each gets its own renamed version.

🔧 Why Use This?

• ✅ Safe — Respects JavaScript scoping rules
• 🔍 Customizable — You control the renaming logic
• 🧰 Tool-friendly — Works directly with standard AST tools
• ⚙️ Flexible — Use it for obfuscation, refactoring, or static analysis

🧩 Try It Out

You can install it via npm:

npm install git+https://github.com/optinsoft/renamedecl.git

Then import and use it as shown above.

💡 Conclusion

Working with ASTs may sound intimidating at first, but with tools like Acorn, Escodegen, and utilities such as renamedecl, transforming JavaScript code becomes powerful and approachable.

By controlling variable and function names at the AST level, you can safely build tools for code analysis, transpilation, refactoring, or obfuscation — all while preserving the correctness of your original code.

ImportError: DLL load failed while importing _driver: DLL load failed

The reason is that pycuda is trying to load the CUDA DLL from the bin directory:

C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v13.0\bin

I am using the latest version of pycuda available at the moment: v2025.1.2.

pycuda\driver.py:

def _add_cuda_libdir_to_dll_path():from os.path import dirname, jointextcuda_path = os.environ.get("CUDA_PATH")if cuda_path is not None:    os.add_dll_directory(join(cuda_path, "bin"))    return

However, in version v13 of the NVIDIA GPU Computing Toolkit, the DLLs are located in the bin\x64 directory:

C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v13.0\bin\x64

To solve this problem, a new setting CUDA_DLL_PATH has been added to settings.ini, which contains the full path to the CUDA DLL.

settings.ini:

[settings]CL_PATH=C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.44.35207\bin\Hostx64\x64CUDA_DLL_PATH=C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v13.0\bin\x64

The latest versions of gen_eth and gen_trx are available on GitHub:

• https://github.com/optinsoft/gen_eth
• https://github.com/optinsoft/gen_trx

PS. If the following error occurs:

pycuda._driver.LogicError: cuModuleLoadDataEx failed: device kernel image is invalid

then you need to update the NVIDIA video driver: https://www.nvidia.com/en-us/drivers/

For the blog migration, I wrote a powershell script called wp-hexo-convertor, which is available on GitHub.

Prior to migration, the WordPress blog was converted to a static version. The wp-hexo-convertor utility was then used to generate posts and redirect pages for Hexo. These redirects are essential to prevent the loss of organic traffic from Google search.

The redirects are implemented via the hexo-generator-alias plugin. I created a GitHub fork that uses the url_for function instead of full_url_for.

Version 2.11 of the IP List Generator has been released.

What’s New

New feature: find ISO country code for the country associated with the IP address.

IP List Generator uses MaxMind’s GeoIP2 binary database (MMDB) to resolve country by IP.

Web Proxy Checker also uses this database to find the country of the proxy by its IP.

MD5 List Generator has been renamed to HASH List Generator.

What’s new: calculating SHA1, SHA-256, SHA-384 and SHA-512 hash values.

Version 1.6.105 of the Opt-In List Manager has been released.

What’s New

Extract And Clean

1. Clean Mail Lists: Remove empty fields (columns).
2. Clean Mail Lists: Custom field (column) delimiters.
3. Clean Mail Lists: The number of output columns. If the source row contains less than the specified number of columns, the list manager will add missing columns (blank). If the source row contains more than the specified number of columns, the list manager will cut extra columns.

Merge E-Mail Lists

1. Keep Email Duplicates (remove full duplicates only).

Misc. Utilites

1. Replace blanks with the specified text.
2. Replace the matched regular expression pattern with the specified text.
3. You can specify field (column) numbers to modify (add prefix, suffix or replace the text).
4. Calculate SHA1, SHA-256 and SHA-512 hash values.

Account Verifier allows to check the validity of email addresses.

1. Select Protocol: SMTP.
2. Check “Extract Servers from accounts“ box.
3. Check “MX Lookup“ box.
4. Select Check For: RCPT TO.