Naomi233's Technical Blog

website·Indexed 30 days ago

https://naomi233.github.io/

A collection of technical guides and reflections covering backend development, server administration, and frontend optimization. Topics include Spring AOP, Go programming, Docker Compose deployments for ElasticSearch 8.x and Gitea + Drone CI, Raspberry Pi setup, Nuxt3 Lighthouse optimization, and network configurations for Mihomo and WSL2.

Tokens
52.6K
Snippets
267
Records
335
Agent score
73%

What's inside Naomi233

  1. Overview of Mihomo (Clash Meta) optimized configuration

    This configuration template for the Mihomo kernel is designed for privacy and ease of maintenance. Key features include:

    • DNS Leak Prevention: Prioritizes domestic DNS for domestic domains and uses overseas DoH for others, ensuring requests follow proxy rules.
    • Multi-Subscription Support: Allows multiple subscription sources via proxy-providers with separated nodes and rules.
    • Automated Maintenance: Scheduled updates for GeoIP, GeoSite, RuleSets, and subscription nodes.
    • Automatic Node Classification: Filters nodes by region (HK, TW, JP, KR, SG, US) and type (Residential, Streaming).
    • Service-Specific Routing: Dedicated policy groups for AI, Streaming, Gaming, Microsoft, Apple, and Google.
    • Routing Strategies: Supports manual selection, lowest latency, failover, and load balancing.
    • Ad Blocking: Built-in basic ad blocking using GeoSite categories.
    • Google Play Optimization: Improves stability for app downloads and updates.
  2. Overview of Mihomo (Clash Meta) optimized configuration

    This configuration template for the Mihomo (Clash Meta) kernel is designed for privacy and ease of maintenance. Key features include:

    • DNS Leak Prevention: Prioritizes domestic DNS for domestic domains and uses overseas DoH for others, ensuring requests follow proxy rules.
    • Multi-Subscription Support: Allows multiple sources in proxy-providers with separated nodes and rules.
    • Automated Updates: Scheduled updates for GeoIP, GeoSite, RuleSets, and subscription nodes.
    • Automatic Node Classification: Filters nodes by region (HK, TW, JP, KR, SG, US) and type (Residential, Streaming).
    • Service-Specific Routing: Dedicated policy groups for AI, Streaming, Gaming, Microsoft, Apple, and Google.
    • Routing Strategies: Supports manual selection, lowest latency, failover, and load balancing.
    • Ad Blocking: Built-in blocking of common ad domains via GeoSite rules.
    • Google Play Optimization: Improves stability for app downloads and updates.
  3. Use slices for flexible data sequences

    Slices wrap arrays to provide a more powerful and convenient interface for sequences of data. Most array programming in Go is performed using slices.

    Slices hold references to an underlying array. Assigning one slice to another results in both referring to the same array. Consequently, changes made to slice elements within a function are visible to the caller, similar to passing a pointer to the underlying array.

  4. Understand Go slice behavior and memory sharing

    A slice in Go holds a reference to an underlying array. When one slice is assigned to another, both slices point to the same underlying array. Consequently, if a function accepts a slice as a parameter and modifies the elements within that slice, the caller will see those changes. This behavior makes slices an efficient way to pass buffers to functions (e.g., for reading data) without needing to pass a pointer and a length separately, as the slice's length inherently defines the upper bound of the data to be read.
  5. Use slices for general sequence data

    Slices wrap arrays to provide a more powerful and convenient interface. Slices hold references to an underlying array; assigning one slice to another results in both referring to the same array. Consequently, changes made to slice elements within a function are visible to the caller, making slices an idiomatic replacement for passing pointers to arrays.
  6. Caddy Automated HTTPS and DNS-01 Validation Overview

    Caddy provides automatic HTTPS by default. It manages the entire lifecycle: ACME registration, domain ownership verification, certificate storage, and automatic renewal (typically starting when 1/3 of the certificate's life remains, or ~30 days before expiry for Let's Encrypt).

    This guide recommends the DNS-01 validation method over HTTP-01 or TLS-ALPN-01 because it does not require open inbound ports (80/443), works behind CDNs or NAT, and is the only method that supports wildcard certificates (*.example.com). DNS-01 works by using a DNS provider's API to create and delete TXT records.

  7. Understand Caddy's Automatic HTTPS and DNS-01 Validation

    Caddy provides automatic HTTPS by default. It manages the entire lifecycle: ACME registration, domain ownership verification, certificate storage, and automatic renewal (typically starting when 1/3 of the certificate's life remains, or ~30 days before expiry for a 90-day certificate).

    This setup specifically uses DNS-01 validation instead of HTTP-01 because:

    1. It does not require open inbound ports (80/443) for verification, making it ideal for servers behind CDNs, NAT, or in internal networks.
    2. It is the only method that supports the issuance of wildcard certificates (e.g., *.example.com).
    3. It requires a DNS provider API key to programmatically create TXT records.
  8. Customizing Caddy with Plugins via xcaddy

    The official caddy:2-alpine image lacks specific DNS and logging plugins. To add these, use xcaddy in a multi-stage Docker build. The following plugins are recommended for this production setup:

    • github.com/caddy-dns/tencentcloud: Enables DNS-01 validation via Tencent Cloud DNSPod API for automatic wildcard certificate issuance and renewal.
    • github.com/caddyserver/transform-encoder: Allows customizing log templates to convert Caddy's default JSON logs into Nginx/Apache Combined Log plain text format.
  9. Optimize Nuxt 3 TTFB using Nitro Storage and Parallel Requests

    To reduce Time to First Byte (TTFB) in Nuxt SSR applications, implement data caching and request optimization. Use Nitro Storage to cache repetitive data (e.g., categories, layouts) to avoid redundant database or GraphQL calls. In multi-instance deployments, use shared storage like Redis to prevent cache fragmentation. Additionally, use Promise.all to execute independent requests in parallel to avoid request waterfalls. For non-critical data (e.g., footers, recommendations), use useLazyRequest with server: false to move the request to the client side, reducing the SSR critical path.
  10. Organize Caddy configurations using snippets and imports

    Use snippets (defined with parentheses) to avoid repeating common configurations (like logging or compression) across multiple sites. Use the import directive to split site configurations into separate files within a directory for better maintainability.
    # Define a snippet for common settings
    (common) {
        # common config here
    }
    
    # Import all site configurations from a directory
    import Caddyfile.d/*.conf
    
    # Inside a site file (e.g., Caddyfile.d/app.conf):
    app.example.com {
        import common
        reverse_proxy localhost:8080
    }
  11. Install WatchDucker

    WatchDucker can be installed via Docker image, binary download, or by compiling from source.
    # Docker installation
    docker pull naomi233/watchducker:latest
    
    # Source compilation
    git clone https://github.com/naomi233/watchducker.git
    cd watchducker
    go build -o watchducker .
  12. Write documentation comments for godoc

    Go uses comments to generate package documentation via the godoc tool.

    • Line Comments: Use // for most comments; this is the standard norm.
    • Block Comments: Use /* */ primarily for package-level comments or disabling large blocks of code.
    • Doc Comments: To associate a comment with a top-level declaration for godoc extraction, place the comment immediately before the declaration with no intervening newlines.
    • Package Comments: Every package should have a package comment (a block comment preceding the package clause) in at least one file to introduce the package's purpose.